[jira] [Created] (LUCENE-4939) Join's TermsIncludingScoreQuery Weight has wrong normalization
David Smiley created LUCENE-4939: Summary: Join's TermsIncludingScoreQuery Weight has wrong normalization Key: LUCENE-4939 URL: https://issues.apache.org/jira/browse/LUCENE-4939 Project: Lucene - Core Issue Type: Bug Components: modules/join Reporter: David Smiley Priority: Minor In the Join module, TermsIncludingScoreQuery's Weight implementation looks suspiciously wrong. It creates a Weight based on the original query and delegates a couple calls to it in getValueForNormalization() and normalize() -- ok fine. But then it doesn't do anything with it! Furthermore, the original query has already been run by this point anyway. Question: Should the original query, which currently runs separately (see JoinUtil), participate in the Weight normalization of the main query? It would be tricky to wire all this together based on the current structure but arguably that is more correct. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-1413) Add MockSolrServer to SolrJ client tests
[ https://issues.apache.org/jira/browse/SOLR-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lance Norskog closed SOLR-1413. --- Resolution: Implemented Fix Version/s: 3.3 The test infrastructure has had a huge upgrade since 3 years ago. This is no longer a valid thang. > Add MockSolrServer to SolrJ client tests > > > Key: SOLR-1413 > URL: https://issues.apache.org/jira/browse/SOLR-1413 > Project: Solr > Issue Type: Test > Components: clients - java > Environment: Any Solr distribution. Uses only the SolrJ client code, > nothing in the Solr core. >Reporter: Lance Norskog >Priority: Minor > Fix For: 3.3 > > Attachments: SOLR-1413.patch, SOLR-1413.patch > > > The SolrJ unit test suite has no "mock" solr server for HTTP access, and > there are no low-level tests of the Solrj HTTP wire protocols. > This patch includes org.apache.solr.client.solrj.MockHTTPServer.java and > org.apache.solr.client.solrj.TestHTTP_XML_single.java. The mock server does > not parse its input and responds with pre-configured byte streams. The latter > does a few tests in the XML wire format. Most of the tests do one request and > set up success and failure responses. > Unfortunately, there is a bug: I could not get 2 successive requests to work. > The mock server's TCP socket does not work when reading the second request. > If someone who knows the JDK socket classes could look at the mock server, I > would greatly appreciate it. > The alternative is to steal a bunch of files from the apache commons > httpclient test suite. This is a quite sophisticate bunch of code: > http://svn.apache.org/repos/asf/httpcomponents/oac.hc3x/trunk/src/test/org/apache/commons/httpclient/server/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX ([[ Exception while replacing ENV. Please report this as a bug. ]]
{{ java.lang.NullPointerException }})
- Build # 404 - Still Failing!
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="=_Part_4_100012749.1366255901256"
X-Jenkins-Job: Lucene-Solr-trunk-MacOSX
X-Jenkins-Result: FAILURE
Precedence: bulk
--=_Part_4_100012749.1366255901256
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/404/
Java: [[ Exception while replacing ENV. Please report this as a bug. ]]
{{ java.lang.NullPointerException }}
No tests ran.
Build Log:
[...truncated 12581 lines...]
FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected
termination of the channel
hudson.remoting.RequestAbortedException:
hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected
termination of the channel
at hudson.remoting.Request.call(Request.java:174)
at hudson.remoting.Channel.call(Channel.java:672)
at
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158)
at com.sun.proxy.$Proxy75.join(Unknown Source)
at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:915)
at hudson.Launcher$ProcStarter.join(Launcher.java:360)
at hudson.tasks.Ant.perform(Ant.java:217)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:802)
at hudson.model.Build$BuildExecution.build(Build.java:199)
at hudson.model.Build$BuildExecution.doRun(Build.java:160)
at
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:584)
at hudson.model.Run.execute(Run.java:1575)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:237)
Caused by: hudson.remoting.RequestAbortedException: java.io.IOException:
Unexpected termination of the channel
at hudson.remoting.Request.abort(Request.java:299)
at hudson.remoting.Channel.terminate(Channel.java:732)
at
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69)
Caused by: java.io.IOException: Unexpected termination of the channel
at
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50)
Caused by: java.io.EOFException
at
java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2577)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1315)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369)
at hudson.remoting.Command.readFrom(Command.java:92)
at
hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59)
at
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)
--=_Part_4_100012749.1366255901256--
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4733) Rollback does not work correctly
Mark S created SOLR-4733:
Summary: Rollback does not work correctly
Key: SOLR-4733
URL: https://issues.apache.org/jira/browse/SOLR-4733
Project: Solr
Issue Type: Bug
Affects Versions: 4.2.1
Environment: Ubuntu 12.04.2 LTS
Reporter: Mark S
I wrote a simple test that seems to reproduce the unexpected behaviour. See the
below test case "addBeanThenRollbackThenAddBeanThenRollbackTest()".
It seems on rollback the bean is not written to Solr system, though I think the
client remembers the bean which then creates a version conflict SolrException.
* *The test case:*
{code:java}
@Test
public void addBeanThenRollbackThenAddBeanThenRollbackTest() throws Exception {
MyTestBean myTestBean = createTestBean("addBeanTest");
UpdateResponse updateResponseOne = server.addBean(myTestBean);
Assert.assertEquals(0, updateResponseOne.getStatus());
rollback();
Thread.sleep(1000);
// No Bean Found
{
MyTestBean myTestBeanStored = getTestBean(myTestBean.getId());
Assert.assertNull(myTestBeanStored);
}
UpdateResponse updateResponseTwo = server.addBean(myTestBean);
Assert.assertEquals(0, updateResponseTwo.getStatus());
rollback();
Thread.sleep(1000);
// No Bean Found
{
MyTestBean myTestBeanStored = getTestBean(myTestBean.getId());
Assert.assertNull(myTestBeanStored);
}
}
{code}
* *The stack trace:*
{code}
org.apache.solr.common.SolrException: version conflict for
154ff2e0-621b-4eb0-a1d3-4bbe7ea01573 expected=-1 actual=1432619355523252224
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:404)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:181)
at
org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:117)
at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:116)
at org.apache.solr.client.solrj.SolrServer.addBean(SolrServer.java:136)
at org.apache.solr.client.solrj.SolrServer.addBean(SolrServer.java:125)
at
test.SolrJBeanTest.addBeanThenRollbackThenAddBeanThenRollbackTest(SolrJBeanTest.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
{code}
* *The test class:*
{code:java}
package test;
import java.io.Serializable;
import java.util.Date;
import java.util.List;
import java.util.Locale;
import java.util.UUID;
import junit.framework.Assert;
import org.apache.solr.client.solrj.SolrQuery;
import org.apache.solr.client.solrj.beans.Field;
import org.apache.solr.client.solrj.impl.BinaryRequestWriter;
import org.apache.solr.client.solrj.impl.HttpSolrServe
[jira] [Closed] (SOLR-4732) CoreAdmin - SWAP and RENAME with shared instanceDir and no dataDir - problems after Solr restart
[
https://issues.apache.org/jira/browse/SOLR-4732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey closed SOLR-4732.
--
Resolution: Invalid
Fix Version/s: (was: 4.3)
Assignee: Shawn Heisey
On IRC, Hoss wondered how this user was able to even get Solr working with this
solr.xml. It became clear when the user said that they have the following in
solrconfig.xml:
{noformat}
${MYSOLRROOT:/mysolrroot}/messages/solr/data/${solr.core.name}
{noformat}
On 3.5, when you rename or swap cores, the solr.core.name property does NOT get
updated until you restart Solr. I have no reason to think that 4.x is any
different, but I have not verified this.
> CoreAdmin - SWAP and RENAME with shared instanceDir and no dataDir - problems
> after Solr restart
>
>
> Key: SOLR-4732
> URL: https://issues.apache.org/jira/browse/SOLR-4732
> Project: Solr
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>
> If your cores share an instanceDir but dataDir is not explicitly defined in
> solr.xml, apparently dataDir is not "./data" as it would be when instanceDir
> is not shared, it becomes (or includes) the name of the core as well. This
> results in problems problems with RENAME, and probably SWAP as well.
> The RENAME will work, with the dataDir still retaining the old name. When
> you restart Solr, however, the core will use the new name for the dataDir and
> create an empty index, ignoring the old one. Based on this behavior, I
> believe that if you did a SWAP, after reload the cores would no longer be
> swapped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4730) Place link to Solr wiki in a more prominent place
[ https://issues.apache.org/jira/browse/SOLR-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved SOLR-4730. --- Resolution: Fixed Fix Version/s: 5.0 4.3 Thanks Uri, nice improvement for the release. About integrating the git instructions: its just something I hacked together but I didn't know the best way to integrate into the regular contributor instructions. I also don't like that these instructions are duplicated across both the lucene and solr wikis when its only one development project. I sent an email with this to the developer list, because I think its vital for these instructions to be as simple as possible, but unfortunately there wasn't much interest (http://search-lucene.com/m/sxPSK1hg8BH/refactoring+howtocontribute&subj=refactoring+HowToContribute) In any case, if you are interested/have ideas, see http://wiki.apache.org/solr/#How_to_edit_this_Wiki If you sign up and get a user name, just ping back and we can give you write access to the wiki. > Place link to Solr wiki in a more prominent place > - > > Key: SOLR-4730 > URL: https://issues.apache.org/jira/browse/SOLR-4730 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Uri Laserson >Priority: Minor > Labels: usability > Fix For: 4.3, 5.0 > > Attachments: SOLR-4730.patch > > > Solr homepage (http://lucene.apache.org/solr/4_2_1/) lists reference docs and > javadocs, but makes it very easy to skip the link to the Wiki. From a new > user's perspective, the wiki is probably the most important, so please make > it more prominent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_17) - Build # 5212 - Failure!
Got it, thanks.
On Wed, Apr 17, 2013 at 3:58 PM, Simon Willnauer
wrote:
> you merge to 4x as usual and then you merge the fix to lucene_solr_4_3 as
> well. you place the Changes notice already in the 4.3 section when you
> commit to trunk.
>
> simon
>
>
> On Wed, Apr 17, 2013 at 9:53 PM, Erick Erickson
> wrote:
>>
>> Simon:
>>
>> I want to be sure I don't mess this up, and never having been a RM I'm
>> not all that familiar with the process. When you say "roll another
>> release" will you merge 4x or do I need to merge any changes I need in
>> 4.3 into lucene_solr_4_3 as well as 4x?
>>
>> Thanks,
>> Erick
>>
>> On Wed, Apr 17, 2013 at 3:24 PM, Robert Muir wrote:
>> > cool, i opened https://issues.apache.org/jira/browse/LUCENE-4938
>> >
>> > We should still have explicit tests for this, and there is still the
>> > mystery
>> > of how this test ever passed at all!
>> >
>> >
>> > On Wed, Apr 17, 2013 at 12:18 PM, Simon Willnauer
>> > wrote:
>> >>
>> >> @rob you can add the fix too if you want that is fine I will roll
>> >> another
>> >> release anyways
>> >>
>> >> simon
>> >>
>> >>
>> >> On Wed, Apr 17, 2013 at 9:14 PM, Robert Muir wrote:
>> >>>
>> >>> I'll open an issue. We should at least fix the test for 4.3 if
>> >>> possible
>> >>> (the indexsearcher change can wait)
>> >>>
>> >>>
>> >>> On Wed, Apr 17, 2013 at 9:19 AM, Robert Muir wrote:
>>
>> I see the bug (two bugs).
>>
>> One bug is the test does IndexSearcher.search(query,
>> Integer.MAX_VALUE,
>> sort)
>>
>> In the case of search-without-sort, there is some code that
>> essentially
>> does Math.min(maxdoc, ndoc) so that if you request more documents
>> than
>> actually exist in the index, we create a smaller priority queue. I
>> think Uwe
>> added that not so long ago. But this code isn't in
>> search-with-sort...
>> Index:
>> lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
>> ===
>> --- lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
>> (revision 1468947)
>> +++ lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
>> (working copy)
>> @@ -511,6 +511,12 @@
>>
>> if (sort == null) throw new NullPointerException("Sort must not
>> be
>> null");
>>
>> +int limit = reader.maxDoc();
>> +if (limit == 0) {
>> + limit = 1;
>> +}
>> +nDocs = Math.min(nDocs, limit);
>> +
>> if (executor == null) {
>> // use all leaves here!
>> return search(leafContexts, weight, after, nDocs, sort,
>> fillFields, doDocScores, doMaxScore);
>> Index:
>>
>> lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
>> ===
>> ---
>>
>> lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
>> (revision 1468947)
>> +++
>>
>> lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
>> (working copy)
>> @@ -69,7 +69,7 @@
>>
>> // Get hits sorted by our FunctionValues (ascending values)
>> Query q = new MatchAllDocsQuery();
>> -TopDocs hits = searcher.search(q, Integer.MAX_VALUE, orderBy);
>> +TopDocs hits = searcher.search(q, reader.maxDoc(), orderBy);
>> assertEquals(NUM_VALS, hits.scoreDocs.length);
>> // Verify that sorting works in general
>> int i = 0;
>> @@ -81,7 +81,7 @@
>> // Now get hits after hit #2 using IS.searchAfter()
>> int afterIdx = 1;
>> FieldDoc afterHit = (FieldDoc) hits.scoreDocs[afterIdx];
>> -hits = searcher.searchAfter(afterHit, q, Integer.MAX_VALUE,
>> orderBy);
>> +hits = searcher.searchAfter(afterHit, q, reader.maxDoc(),
>> orderBy);
>>
>> // Expected # of hits: NUM_VALS - 2
>> assertEquals(NUM_VALS - (afterIdx + 1), hits.scoreDocs.length);
>>
>>
>> On Wed, Apr 17, 2013 at 10:54 AM, Policeman Jenkins Server
>> wrote:
>> >
>> > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/5212/
>> > Java: 32bit/jdk1.7.0_17 -client -XX:+UseG1GC
>> >
>> > 1 tests failed.
>> > REGRESSION:
>> >
>> > org.apache.lucene.queries.function.TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues
>> >
>> > Error Message:
>> > Requested array size exceeds VM limit
>> >
>> > Stack Trace:
>> > java.lang.OutOfMemoryError: Requested array size exceeds VM limit
>> > at
>> >
>> > __randomizedtesting.SeedInfo.seed([19CBB97056276D92:E7ABF8B5EEE0EA22]:0)
>> > at
>> > org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:64)
>> >
[jira] [Commented] (SOLR-4725) Should we stop supporting "name" and "dataDir" in the autodiscover mode?
[ https://issues.apache.org/jira/browse/SOLR-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634740#comment-13634740 ] Erick Erickson commented on SOLR-4725: -- Currently, the logic (discovery mode) is that if the name property is NOT present, the name defaults to the directory that contains core.properties. If name _is_ present, then it's used. None of this JIRA is about whether or not to have a name attribute, it's all about if the name parameter is specified in two different properties files and is the same in both. E.g. your setup is solrhome/core1/core.properties contains the attribute name=foo and solrhome/core2/core.properties contains the attribute name=foo What's the correct thing to do? I claim that this probably wasn't intended; there's no good way to dis-entangle this knot so we should fail to open either core, forcing the user to straighten this out b/c it certainly (IMO) is an error. I _think_ the current behavior with the tags in solr.xml is that last one wins, but which one is last depends on the vagaries of the XML parser, deterministic, but not necessarily easy to figure out. Not quite sure what the right thing to do in terms of persisting the name if it's not present originally, I can see the advantage of doing that though. Might even happen automagically, I'd have to look back at the persist code again. Nor would I be averse to making the name attribute mandatory, although I haven't thought it through thoroughly. JIRA's welcome. > Should we stop supporting "name" and "dataDir" in the autodiscover mode? > > > Key: SOLR-4725 > URL: https://issues.apache.org/jira/browse/SOLR-4725 > Project: Solr > Issue Type: New Feature >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Blocker > Attachments: SOLR-4725.patch > > > Making this a blocker so we resolve it. Should be quick to code if we have > consensus, maybe nothing at all to do here. > I'm not too happy with the fact that the new core discovery process has two > real gotcha's. The individual core.properties file can define 'name' and > 'dataDir'. It seems too easy to either use the same name for two different > cores or use the same dataDir, just copy the core.properties file around and > fail to edit one them. In large installations this could be a bear to track > down. > Straw-man proposal is the we remove support for them both in discovery mode. > The name defaults to the directory in which core.properties is found and the > data dir is immediately below there. > Currently, there are checks to fail to load either core if either 'name' or > 'dataDir' is defined in more than one core. I think the error reporting is > weak, you probably have to look in the log file and there should be a way to > get this in the admin UI at least. > Maybe the right thing to do is just leave it as-is and emphasize that > specifying the dataDir and name is expert level and you have to get it right, > but I wanted to get wider exposure to the problem before we push 4.3 out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4731) Fresh clone of github lucene-solr repo already has modified files somehow
[ https://issues.apache.org/jira/browse/SOLR-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634738#comment-13634738 ] Robert Muir commented on SOLR-4731: --- What operating system are you using? I wonder if its a newline issue of some sort... > Fresh clone of github lucene-solr repo already has modified files somehow > - > > Key: SOLR-4731 > URL: https://issues.apache.org/jira/browse/SOLR-4731 > Project: Solr > Issue Type: Bug >Reporter: Uri Laserson > > I forked the lucene-solr repo on github. > Then > git clone g...@github.com:laserson/lucene-solr.git > Then `git status` gives me > $ git status > # On branch trunk > # Changes not staged for commit: > # (use "git add ..." to update what will be committed) > # (use "git checkout -- ..." to discard changes in working directory) > # > # modified: solr/example/cloud-scripts/zkcli.bat > # > no changes added to commit (use "git add" and/or "git commit -a") > Even though I never touched anything -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4701) CollectorFilterQParserPlugin support Filter Collector at search with PostFilter
[
https://issues.apache.org/jira/browse/SOLR-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634618#comment-13634618
]
Yonik Seeley commented on SOLR-4701:
Could you explain the approach used, in particular how it differs from the
existing "frange" (function range) functionality that now has the PostFilter
ability?
http://yonik.com/posts/advanced-filter-caching-in-solr/
http://yonik.com/posts/ranges-over-functions-in-solr-1-4/
> CollectorFilterQParserPlugin support Filter Collector at search with
> PostFilter
> ---
>
> Key: SOLR-4701
> URL: https://issues.apache.org/jira/browse/SOLR-4701
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.2
>Reporter: Linbin Chen
> Fix For: 4.3
>
> Attachments: SOLR-4701.patch
>
>
> example:
> * {code}fq={!cf name=in}status:(-1, 2){code}
> * {code}fq={!cf name=in not=true}status:(3,4){code}
> * {code}fq={!cf name=range}price:[100 TO 500]{code}
> * {code}fq={!cf name=range}log(page_view):[50 TO 120]{code}
> in operate like sql in， faster then OR boolean query.
> most of the case, range faster then TrieField in lucene query.
> how to do use:
> solrconfig.xml add
> {code:xml}
>
> {code}
> cf not use query cache, use PostFilter fiter collector
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4730) Place link to Solr wiki in a more prominent place
[ https://issues.apache.org/jira/browse/SOLR-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634555#comment-13634555 ] Uwe Schindler commented on SOLR-4730: - Lucene trunk which will be Lucene 5.0 needs Java 7. > Place link to Solr wiki in a more prominent place > - > > Key: SOLR-4730 > URL: https://issues.apache.org/jira/browse/SOLR-4730 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Uri Laserson >Priority: Minor > Labels: usability > Attachments: SOLR-4730.patch > > > Solr homepage (http://lucene.apache.org/solr/4_2_1/) lists reference docs and > javadocs, but makes it very easy to skip the link to the Wiki. From a new > user's perspective, the wiki is probably the most important, so please make > it more prominent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4732) CoreAdmin - SWAP and RENAME with shared instanceDir and no dataDir - problems after Solr restart
[ https://issues.apache.org/jira/browse/SOLR-4732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634540#comment-13634540 ] Shawn Heisey commented on SOLR-4732: I'm not sure how this should be fixed. SOLR-4662 and SOLR-4725 make some pretty radical changes to how cores work. > CoreAdmin - SWAP and RENAME with shared instanceDir and no dataDir - problems > after Solr restart > > > Key: SOLR-4732 > URL: https://issues.apache.org/jira/browse/SOLR-4732 > Project: Solr > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Shawn Heisey > Fix For: 4.3 > > > If your cores share an instanceDir but dataDir is not explicitly defined in > solr.xml, apparently dataDir is not "./data" as it would be when instanceDir > is not shared, it becomes (or includes) the name of the core as well. This > results in problems problems with RENAME, and probably SWAP as well. > The RENAME will work, with the dataDir still retaining the old name. When > you restart Solr, however, the core will use the new name for the dataDir and > create an empty index, ignoring the old one. Based on this behavior, I > believe that if you did a SWAP, after reload the cores would no longer be > swapped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4732) CoreAdmin - SWAP and RENAME with shared instanceDir and no dataDir - problems after Solr restart
[
https://issues.apache.org/jira/browse/SOLR-4732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634531#comment-13634531
]
Shawn Heisey commented on SOLR-4732:
This is the solr.xml the user had, on Solr 3.5:
{noformat}
...
{noformat}
> CoreAdmin - SWAP and RENAME with shared instanceDir and no dataDir - problems
> after Solr restart
>
>
> Key: SOLR-4732
> URL: https://issues.apache.org/jira/browse/SOLR-4732
> Project: Solr
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Shawn Heisey
> Fix For: 4.3
>
>
> If your cores share an instanceDir but dataDir is not explicitly defined in
> solr.xml, apparently dataDir is not "./data" as it would be when instanceDir
> is not shared, it becomes (or includes) the name of the core as well. This
> results in problems problems with RENAME, and probably SWAP as well.
> The RENAME will work, with the dataDir still retaining the old name. When
> you restart Solr, however, the core will use the new name for the dataDir and
> create an empty index, ignoring the old one. Based on this behavior, I
> believe that if you did a SWAP, after reload the cores would no longer be
> swapped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4732) CoreAdmin - SWAP and RENAME with shared instanceDir and no dataDir - problems after Solr restart
Shawn Heisey created SOLR-4732: -- Summary: CoreAdmin - SWAP and RENAME with shared instanceDir and no dataDir - problems after Solr restart Key: SOLR-4732 URL: https://issues.apache.org/jira/browse/SOLR-4732 Project: Solr Issue Type: Bug Affects Versions: 3.5 Reporter: Shawn Heisey Fix For: 4.3 If your cores share an instanceDir but dataDir is not explicitly defined in solr.xml, apparently dataDir is not "./data" as it would be when instanceDir is not shared, it becomes (or includes) the name of the core as well. This results in problems problems with RENAME, and probably SWAP as well. The RENAME will work, with the dataDir still retaining the old name. When you restart Solr, however, the core will use the new name for the dataDir and create an empty index, ignoring the old one. Based on this behavior, I believe that if you did a SWAP, after reload the cores would no longer be swapped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4730) Place link to Solr wiki in a more prominent place
[ https://issues.apache.org/jira/browse/SOLR-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634526#comment-13634526 ] Uri Laserson commented on SOLR-4730: Patch is attached. The github instructions should be integrated with the other HowTo page. Also, couldn't build the docs: Buildfile: /Users/laserson/repos/lucene-solr/build.xml documentation: BUILD FAILED /Users/laserson/repos/lucene-solr/build.xml:53: The following error occurred while executing this line: /Users/laserson/repos/lucene-solr/lucene/build.xml:23: The following error occurred while executing this line: /Users/laserson/repos/lucene-solr/lucene/common-build.xml:287: Minimum supported Java version is 1.7. > Place link to Solr wiki in a more prominent place > - > > Key: SOLR-4730 > URL: https://issues.apache.org/jira/browse/SOLR-4730 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Uri Laserson >Priority: Minor > Labels: usability > Attachments: SOLR-4730.patch > > > Solr homepage (http://lucene.apache.org/solr/4_2_1/) lists reference docs and > javadocs, but makes it very easy to skip the link to the Wiki. From a new > user's perspective, the wiki is probably the most important, so please make > it more prominent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4730) Place link to Solr wiki in a more prominent place
[ https://issues.apache.org/jira/browse/SOLR-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Laserson updated SOLR-4730: --- Attachment: SOLR-4730.patch > Place link to Solr wiki in a more prominent place > - > > Key: SOLR-4730 > URL: https://issues.apache.org/jira/browse/SOLR-4730 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Uri Laserson >Priority: Minor > Labels: usability > Attachments: SOLR-4730.patch > > > Solr homepage (http://lucene.apache.org/solr/4_2_1/) lists reference docs and > javadocs, but makes it very easy to skip the link to the Wiki. From a new > user's perspective, the wiki is probably the most important, so please make > it more prominent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4731) Fresh clone of github lucene-solr repo already has modified files somehow
Uri Laserson created SOLR-4731: -- Summary: Fresh clone of github lucene-solr repo already has modified files somehow Key: SOLR-4731 URL: https://issues.apache.org/jira/browse/SOLR-4731 Project: Solr Issue Type: Bug Reporter: Uri Laserson I forked the lucene-solr repo on github. Then git clone g...@github.com:laserson/lucene-solr.git Then `git status` gives me $ git status # On branch trunk # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: solr/example/cloud-scripts/zkcli.bat # no changes added to commit (use "git add" and/or "git commit -a") Even though I never touched anything -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4725) Should we stop supporting "name" and "dataDir" in the autodiscover mode?
[ https://issues.apache.org/jira/browse/SOLR-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634505#comment-13634505 ] Mark Miller commented on SOLR-4725: --- bq. I think that a message should be logged saying that certain API actions like SWAP and RENAME will not be available -1, these should not become unavailable because of something like that. bq. cores named on the API call in the 'core' and 'other' parameters. That is irrespective of this issue - the name is a required param for core admin calls. > Should we stop supporting "name" and "dataDir" in the autodiscover mode? > > > Key: SOLR-4725 > URL: https://issues.apache.org/jira/browse/SOLR-4725 > Project: Solr > Issue Type: New Feature >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Blocker > Attachments: SOLR-4725.patch > > > Making this a blocker so we resolve it. Should be quick to code if we have > consensus, maybe nothing at all to do here. > I'm not too happy with the fact that the new core discovery process has two > real gotcha's. The individual core.properties file can define 'name' and > 'dataDir'. It seems too easy to either use the same name for two different > cores or use the same dataDir, just copy the core.properties file around and > fail to edit one them. In large installations this could be a bear to track > down. > Straw-man proposal is the we remove support for them both in discovery mode. > The name defaults to the directory in which core.properties is found and the > data dir is immediately below there. > Currently, there are checks to fail to load either core if either 'name' or > 'dataDir' is defined in more than one core. I think the error reporting is > weak, you probably have to look in the log file and there should be a way to > get this in the admin UI at least. > Maybe the right thing to do is just leave it as-is and emphasize that > specifying the dataDir and name is expert level and you have to get it right, > but I wanted to get wider exposure to the problem before we push 4.3 out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4725) Should we stop supporting "name" and "dataDir" in the autodiscover mode?
[ https://issues.apache.org/jira/browse/SOLR-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634500#comment-13634500 ] Shawn Heisey commented on SOLR-4725: If you have cores that don't have explicit name attributes, I think that a message should be logged saying that certain API actions like SWAP and RENAME will not be available. I don't know if it should be WARN or INFO. It would be OK if the message is only logged when the core is first loaded, not on RELOAD. Similarly, those actions should not be allowed when the name attribute is missing from cores named on the API call in the 'core' and 'other' parameters. If they are attempted an ERROR should be logged and returned in the http response. Or we could avoid that whole can of worms by making the name attribute mandatory, pretty much the exact opposite of this issue. :) The dataDir parameter is currently optional. There was a problem with RENAME on the mailing list today where a user had all their cores sharing the same instanceDir, but dataDir was missing on all of them. I will go ahead and file an issue for that. Is sharing an instanceDir possible with automatic core discovery? > Should we stop supporting "name" and "dataDir" in the autodiscover mode? > > > Key: SOLR-4725 > URL: https://issues.apache.org/jira/browse/SOLR-4725 > Project: Solr > Issue Type: New Feature >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Blocker > Attachments: SOLR-4725.patch > > > Making this a blocker so we resolve it. Should be quick to code if we have > consensus, maybe nothing at all to do here. > I'm not too happy with the fact that the new core discovery process has two > real gotcha's. The individual core.properties file can define 'name' and > 'dataDir'. It seems too easy to either use the same name for two different > cores or use the same dataDir, just copy the core.properties file around and > fail to edit one them. In large installations this could be a bear to track > down. > Straw-man proposal is the we remove support for them both in discovery mode. > The name defaults to the directory in which core.properties is found and the > data dir is immediately below there. > Currently, there are checks to fail to load either core if either 'name' or > 'dataDir' is defined in more than one core. I think the error reporting is > weak, you probably have to look in the log file and there should be a way to > get this in the admin UI at least. > Maybe the right thing to do is just leave it as-is and emphasize that > specifying the dataDir and name is expert level and you have to get it right, > but I wanted to get wider exposure to the problem before we push 4.3 out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-4718: -- Comment: was deleted (was: Yes, it certainly is, and it will run fine. The reason we don't necessarily recommend it is that the solr nodes running zk become somewhat special and zk runs in the same process as Solr - it becomes harder to manage this than if you simply have a separate zk ensemble, which is really just as easy to do. It's simply a recommendation based on the logistics - embedded zk is full and functional and fault tolerant zk. - Mark ) > Allow solr.xml to be stored in zookeeper > > > Key: SOLR-4718 > URL: https://issues.apache.org/jira/browse/SOLR-4718 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson > > So the near-final piece of this puzzle is to make solr.xml be storable in > Zookeeper. Code-wise in terms of Solr, this doesn't look very difficult, I'm > working on it now. > More interesting is how to get the configuration into ZK in the first place, > enhancements to ZkCli? Or boostrap-conf? Other? I'm punting on that for this > patch. > Second level is how to tell Solr to get the file from ZK. Some possibilities: > 1> A system prop, -DzkSolrXmlPath=blah where blah is the path _on zk_ where > the file is. Would require -DzkHost or -DzkRun as well. > > pros - simple, I can wrap my head around it. > - easy to script > > cons - can't run multiple JVMs pointing to different files. Is this > really a problem? > 2> New solr.xml element. Something like: > > > zkurl > whatever > > >Really, this form would hinge on the presence or absence of zkSolrXmlPath. > If present, go up and look for the indicated solr.xml file on ZK. Any > properties in the ZK version would overwrite anything in the local copy. > NOTE: I'm really not very interested in supporting this as an option for > old-style solr.xml unless it's _really_ easy. For instance, what if the local > solr.xml is new-style and the one in ZK is old-style? Or vice-versa? Since > old-style is going away, this doesn't seem like it's worth the effort. > pros - No new mechanisms > cons - once again requires that there be a solr.xml file on each client. > Admittedly for installations that didn't care much about multiple JVMs, it > could be a stock file that didn't change... > For now, I'm going to just manually push solr.xml to ZK, then read it based > on a sysprop. That'll get the structure in place while we debate. Not going > to check this in until there's some consensus though. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634497#comment-13634497 ] Mark Miller commented on SOLR-4718: --- bq. I don't even know if it's possible to set up a fully functional fault-tolerant ensemble using the embedded zookeeper. Yes, it certainly is, and it will run fine. The reason we don't necessarily recommend it is that the solr nodes running zk become somewhat special and zk runs in the same process as Solr - it becomes harder to manage this than if you simply have a separate zk ensemble, which is really just as easy to do. y It's simply a recommendation based on the logistics - embedded zk is a fully functional and fault tolerant zk. Not sure where you go the idea otherwise. > Allow solr.xml to be stored in zookeeper > > > Key: SOLR-4718 > URL: https://issues.apache.org/jira/browse/SOLR-4718 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson > > So the near-final piece of this puzzle is to make solr.xml be storable in > Zookeeper. Code-wise in terms of Solr, this doesn't look very difficult, I'm > working on it now. > More interesting is how to get the configuration into ZK in the first place, > enhancements to ZkCli? Or boostrap-conf? Other? I'm punting on that for this > patch. > Second level is how to tell Solr to get the file from ZK. Some possibilities: > 1> A system prop, -DzkSolrXmlPath=blah where blah is the path _on zk_ where > the file is. Would require -DzkHost or -DzkRun as well. > > pros - simple, I can wrap my head around it. > - easy to script > > cons - can't run multiple JVMs pointing to different files. Is this > really a problem? > 2> New solr.xml element. Something like: > > > zkurl > whatever > > >Really, this form would hinge on the presence or absence of zkSolrXmlPath. > If present, go up and look for the indicated solr.xml file on ZK. Any > properties in the ZK version would overwrite anything in the local copy. > NOTE: I'm really not very interested in supporting this as an option for > old-style solr.xml unless it's _really_ easy. For instance, what if the local > solr.xml is new-style and the one in ZK is old-style? Or vice-versa? Since > old-style is going away, this doesn't seem like it's worth the effort. > pros - No new mechanisms > cons - once again requires that there be a solr.xml file on each client. > Admittedly for installations that didn't care much about multiple JVMs, it > could be a stock file that didn't change... > For now, I'm going to just manually push solr.xml to ZK, then read it based > on a sysprop. That'll get the structure in place while we debate. Not going > to check this in until there's some consensus though. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634496#comment-13634496 ] Mark Miller commented on SOLR-4718: --- Yes, it certainly is, and it will run fine. The reason we don't necessarily recommend it is that the solr nodes running zk become somewhat special and zk runs in the same process as Solr - it becomes harder to manage this than if you simply have a separate zk ensemble, which is really just as easy to do. It's simply a recommendation based on the logistics - embedded zk is full and functional and fault tolerant zk. - Mark > Allow solr.xml to be stored in zookeeper > > > Key: SOLR-4718 > URL: https://issues.apache.org/jira/browse/SOLR-4718 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson > > So the near-final piece of this puzzle is to make solr.xml be storable in > Zookeeper. Code-wise in terms of Solr, this doesn't look very difficult, I'm > working on it now. > More interesting is how to get the configuration into ZK in the first place, > enhancements to ZkCli? Or boostrap-conf? Other? I'm punting on that for this > patch. > Second level is how to tell Solr to get the file from ZK. Some possibilities: > 1> A system prop, -DzkSolrXmlPath=blah where blah is the path _on zk_ where > the file is. Would require -DzkHost or -DzkRun as well. > > pros - simple, I can wrap my head around it. > - easy to script > > cons - can't run multiple JVMs pointing to different files. Is this > really a problem? > 2> New solr.xml element. Something like: > > > zkurl > whatever > > >Really, this form would hinge on the presence or absence of zkSolrXmlPath. > If present, go up and look for the indicated solr.xml file on ZK. Any > properties in the ZK version would overwrite anything in the local copy. > NOTE: I'm really not very interested in supporting this as an option for > old-style solr.xml unless it's _really_ easy. For instance, what if the local > solr.xml is new-style and the one in ZK is old-style? Or vice-versa? Since > old-style is going away, this doesn't seem like it's worth the effort. > pros - No new mechanisms > cons - once again requires that there be a solr.xml file on each client. > Admittedly for installations that didn't care much about multiple JVMs, it > could be a stock file that didn't change... > For now, I'm going to just manually push solr.xml to ZK, then read it based > on a sysprop. That'll get the structure in place while we debate. Not going > to check this in until there's some consensus though. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634473#comment-13634473 ] Shawn Heisey commented on SOLR-4718: bq. What are the cons to always using ZK? I missed this question from Erik when I was looking earlier. The primary problem I see with always using zookeeper takes a little explanation. In a non-ZK install, making Solr fault tolerant for queries is fairly easy - fire up another node and set up replication. That's not true fault tolerance, as we all know. Running the embedded zookeeper is something we don't recommend to people except for single-server proof of concept setups. I don't even know if it's possible to set up a fully functional fault-tolerant ensemble using the embedded zookeeper. Unfortunately, setting up a standalone ensemble is not trivial. It's not HARD, but when you go from just running "java -jar start.jar" on a single server to a real-world SolrCloud, either you have to start over or you end up performing arcane rituals to migrate your existing setup. In my opinion, it is a generally bad idea to have step-by-step documentation that results in a setup that isn't fault tolerant. I have used a lot of open source software with documentation like this. If documentation about adding redundancy exists, it is often found in a completely different location as reference material, not step-by-step instructions. Our SolrCloud examples encourage setting up separate Solr JVMs on the same server with the embedded zookeeper. Because that's the available documentation, there are probably production installs set up this way. I think that kind of setup should be in footnotes or appendices, and the main examples should be multi-node, with clear instructions about how to make sure it won't break when something fails. I'm not sure how to make it easy to set up zookeeper. Cross-platform scripting is not easy, especially when one of those platforms is Windows. > Allow solr.xml to be stored in zookeeper > > > Key: SOLR-4718 > URL: https://issues.apache.org/jira/browse/SOLR-4718 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson > > So the near-final piece of this puzzle is to make solr.xml be storable in > Zookeeper. Code-wise in terms of Solr, this doesn't look very difficult, I'm > working on it now. > More interesting is how to get the configuration into ZK in the first place, > enhancements to ZkCli? Or boostrap-conf? Other? I'm punting on that for this > patch. > Second level is how to tell Solr to get the file from ZK. Some possibilities: > 1> A system prop, -DzkSolrXmlPath=blah where blah is the path _on zk_ where > the file is. Would require -DzkHost or -DzkRun as well. > > pros - simple, I can wrap my head around it. > - easy to script > > cons - can't run multiple JVMs pointing to different files. Is this > really a problem? > 2> New solr.xml element. Something like: > > > zkurl > whatever > > >Really, this form would hinge on the presence or absence of zkSolrXmlPath. > If present, go up and look for the indicated solr.xml file on ZK. Any > properties in the ZK version would overwrite anything in the local copy. > NOTE: I'm really not very interested in supporting this as an option for > old-style solr.xml unless it's _really_ easy. For instance, what if the local > solr.xml is new-style and the one in ZK is old-style? Or vice-versa? Since > old-style is going away, this doesn't seem like it's worth the effort. > pros - No new mechanisms > cons - once again requires that there be a solr.xml file on each client. > Admittedly for installations that didn't care much about multiple JVMs, it > could be a stock file that didn't change... > For now, I'm going to just manually push solr.xml to ZK, then read it based > on a sysprop. That'll get the structure in place while we debate. Not going > to check this in until there's some consensus though. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4730) Place link to Solr wiki in a more prominent place
[ https://issues.apache.org/jira/browse/SOLR-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634472#comment-13634472 ] Robert Muir commented on SOLR-4730: --- yeah, lucene-solr github repo is essentially the same. I have some rough instructions for using that here: http://wiki.apache.org/lucene-java/HowToContributeFastPath > Place link to Solr wiki in a more prominent place > - > > Key: SOLR-4730 > URL: https://issues.apache.org/jira/browse/SOLR-4730 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Uri Laserson >Priority: Minor > Labels: usability > > Solr homepage (http://lucene.apache.org/solr/4_2_1/) lists reference docs and > javadocs, but makes it very easy to skip the link to the Wiki. From a new > user's perspective, the wiki is probably the most important, so please make > it more prominent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4730) Place link to Solr wiki in a more prominent place
[ https://issues.apache.org/jira/browse/SOLR-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634467#comment-13634467 ] Robert Muir commented on SOLR-4730: --- after you modify the file, you can run 'ant documentation' from solr/, and then look in solr/build/docs/index.html in your browser to see the generated file. > Place link to Solr wiki in a more prominent place > - > > Key: SOLR-4730 > URL: https://issues.apache.org/jira/browse/SOLR-4730 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Uri Laserson >Priority: Minor > Labels: usability > > Solr homepage (http://lucene.apache.org/solr/4_2_1/) lists reference docs and > javadocs, but makes it very easy to skip the link to the Wiki. From a new > user's perspective, the wiki is probably the most important, so please make > it more prominent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4730) Place link to Solr wiki in a more prominent place
[ https://issues.apache.org/jira/browse/SOLR-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634466#comment-13634466 ] Uri Laserson commented on SOLR-4730: Is the lucene-solr github repo the same thing as the svn repo referenced in the HowToContribute page? > Place link to Solr wiki in a more prominent place > - > > Key: SOLR-4730 > URL: https://issues.apache.org/jira/browse/SOLR-4730 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Uri Laserson >Priority: Minor > Labels: usability > > Solr homepage (http://lucene.apache.org/solr/4_2_1/) lists reference docs and > javadocs, but makes it very easy to skip the link to the Wiki. From a new > user's perspective, the wiki is probably the most important, so please make > it more prominent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4730) Place link to Solr wiki in a more prominent place
[ https://issues.apache.org/jira/browse/SOLR-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634465#comment-13634465 ] Uri Laserson commented on SOLR-4730: Sure...one sec... > Place link to Solr wiki in a more prominent place > - > > Key: SOLR-4730 > URL: https://issues.apache.org/jira/browse/SOLR-4730 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Uri Laserson >Priority: Minor > Labels: usability > > Solr homepage (http://lucene.apache.org/solr/4_2_1/) lists reference docs and > javadocs, but makes it very easy to skip the link to the Wiki. From a new > user's perspective, the wiki is probably the most important, so please make > it more prominent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4730) Place link to Solr wiki in a more prominent place
[ https://issues.apache.org/jira/browse/SOLR-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634463#comment-13634463 ] Robert Muir commented on SOLR-4730: --- By the way, this page is generated automatically from http://svn.apache.org/repos/asf/lucene/dev/trunk/solr/site/xsl/index.xsl in our regular source tree (solr/site/xsl/index.xsl in your checkout) Uri, want to contribute a patch to improve this thing? See http://wiki.apache.org/lucene-java/HowToContribute > Place link to Solr wiki in a more prominent place > - > > Key: SOLR-4730 > URL: https://issues.apache.org/jira/browse/SOLR-4730 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Uri Laserson >Priority: Minor > Labels: usability > > Solr homepage (http://lucene.apache.org/solr/4_2_1/) lists reference docs and > javadocs, but makes it very easy to skip the link to the Wiki. From a new > user's perspective, the wiki is probably the most important, so please make > it more prominent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4730) Place link to Solr wiki in a more prominent place
[
https://issues.apache.org/jira/browse/SOLR-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634460#comment-13634460
]
Robert Muir commented on SOLR-4730:
---
Nice idea:
maybe instead of:
{noformat}
This is the official documentation for Apache Solr 4.2.1. Additional
documentation is available in the Wiki.
Reference Documents
Changes: List of changes in this release.
{noformat}
something like:
{noformat}
This is the official documentation for Apache Solr 4.2.1
Reference Documents
Solr wiki:
Changes: List of changes in this release.
{noformat}
> Place link to Solr wiki in a more prominent place
> -
>
> Key: SOLR-4730
> URL: https://issues.apache.org/jira/browse/SOLR-4730
> Project: Solr
> Issue Type: Improvement
> Components: documentation
>Reporter: Uri Laserson
>Priority: Minor
> Labels: usability
>
> Solr homepage (http://lucene.apache.org/solr/4_2_1/) lists reference docs and
> javadocs, but makes it very easy to skip the link to the Wiki. From a new
> user's perspective, the wiki is probably the most important, so please make
> it more prominent.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4730) Place link to Solr wiki in a more prominent place
Uri Laserson created SOLR-4730: -- Summary: Place link to Solr wiki in a more prominent place Key: SOLR-4730 URL: https://issues.apache.org/jira/browse/SOLR-4730 Project: Solr Issue Type: Improvement Components: documentation Reporter: Uri Laserson Priority: Minor Solr homepage (http://lucene.apache.org/solr/4_2_1/) lists reference docs and javadocs, but makes it very easy to skip the link to the Wiki. From a new user's perspective, the wiki is probably the most important, so please make it more prominent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4661) Index Version & Gen look out of sync in replication UI when master searcher uses older commit then what is replicatable
[
https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-4661.
Resolution: Fixed
Fix Version/s: 5.0
4.3
Assignee: Hoss Man
Committed revision 1469073.
Committed revision 1469074.
Committed revision 1469076.
> Index Version & Gen look out of sync in replication UI when master searcher
> uses older commit then what is replicatable
> ---
>
> Key: SOLR-4661
> URL: https://issues.apache.org/jira/browse/SOLR-4661
> Project: Solr
> Issue Type: Bug
> Components: replication (java), web gui
>Affects Versions: 4.2
> Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7
>Reporter: Aditya
>Assignee: Hoss Man
> Labels: gui, replication, web
> Fix For: 4.3, 5.0
>
> Attachments: hoss_test.zip, IndexVersionSyncIssue.jpg,
> SOLR-4661.patch, SOLR-4661.patch, SOLR-4661.patch
>
>
> the ReplicationHandler (and the replication admin UI screen) report the index
> version & gen for the master based on what commit point is currently open for
> searching -- but this is not necessarily the most recent commit point
> available for replication.
> Thus, it can appear that a slave has "gotten ahead" of the master, if there
> are "empty commits" (because of reader reopening shotcuts) or commits using
> openSearcher=false.
> We need to add additional data to help make it clear there is no actual
> problem in this sitation.
> Summary of original bug report..
> {panel}
> Index and Gen number on Slave is higher than master.
> If you apply commit on master with no pending docs then the commit time stamp
> and gen is incremented. When Slaves polls master for replication it see the
> index version difference and starts replicating but all files are skipped.
> On Admin UI (on Slaves) the version number displayed for master is old where
> as for slave is the latest which is higher than master.
> Below is the response from master (/replication?command=details) where i see
> two different Version an Gen numbers. This creates confusion of having
> version out of sync, though its not.
> ...
> {panel}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_17) - Build # 5162 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/5162/ Java: 32bit/jdk1.7.0_17 -server -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testDistribSearch Error Message: There are still nodes recoverying - waited for 230 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 230 seconds at __randomizedtesting.SeedInfo.seed([68EC35FBF8A6534C:E90ABBE38FF93370]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:173) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:131) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:126) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:509) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:145) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:806) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at
[jira] [Updated] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-4662: - Attachment: SOLR-4662.patch OK, this has both change Mark and I were discussing. Tests pass, but I didn't think to make the change to the default persist before I ran the tests, so that change hasn't made it through all the tests and I have to leave > Finalize what we're going to do with solr.xml, auto-discovery, config sets. > --- > > Key: SOLR-4662 > URL: https://issues.apache.org/jira/browse/SOLR-4662 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Mark Miller >Priority: Blocker > Attachments: SOLR-4662.patch, SOLR-4662.patch, SOLR-4662.patch, > SOLR-4662.patch, SOLR-4662.patch, SOLR-4662.patch > > > Spinoff from SOLR-4615, breaking it out here so we can address the changes in > pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4725) Should we stop supporting "name" and "dataDir" in the autodiscover mode?
[ https://issues.apache.org/jira/browse/SOLR-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634432#comment-13634432 ] Mark Miller commented on SOLR-4725: --- I focused so much on dataDir, I didn't even really consider name (also hadn't just been in the code as I have been now). I agree that support for name should remain in the properties - and that as it does at the moment, if it's absent, we just default it to the dir name. Perhaps we should populate the properties file with it as well, and not count on the dir name over time. > Should we stop supporting "name" and "dataDir" in the autodiscover mode? > > > Key: SOLR-4725 > URL: https://issues.apache.org/jira/browse/SOLR-4725 > Project: Solr > Issue Type: New Feature >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Blocker > Attachments: SOLR-4725.patch > > > Making this a blocker so we resolve it. Should be quick to code if we have > consensus, maybe nothing at all to do here. > I'm not too happy with the fact that the new core discovery process has two > real gotcha's. The individual core.properties file can define 'name' and > 'dataDir'. It seems too easy to either use the same name for two different > cores or use the same dataDir, just copy the core.properties file around and > fail to edit one them. In large installations this could be a bear to track > down. > Straw-man proposal is the we remove support for them both in discovery mode. > The name defaults to the directory in which core.properties is found and the > data dir is immediately below there. > Currently, there are checks to fail to load either core if either 'name' or > 'dataDir' is defined in more than one core. I think the error reporting is > weak, you probably have to look in the log file and there should be a way to > get this in the admin UI at least. > Maybe the right thing to do is just leave it as-is and emphasize that > specifying the dataDir and name is expert level and you have to get it right, > but I wanted to get wider exposure to the problem before we push 4.3 out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4725) Should we stop supporting "name" and "dataDir" in the autodiscover mode?
[ https://issues.apache.org/jira/browse/SOLR-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634429#comment-13634429 ] Shawn Heisey commented on SOLR-4725: If you get rid of the name attribute, how do you decide what the name of the core is? Is it the name of the directory that contains core.properties? What happens if you issue a SWAP or RENAME action and don't have a name attribute? The logical thing would be to rename the directory, but if you're on Windows, you can't do that as long as any process (not just Solr) has anything open anywhere in the entire directory tree. > Should we stop supporting "name" and "dataDir" in the autodiscover mode? > > > Key: SOLR-4725 > URL: https://issues.apache.org/jira/browse/SOLR-4725 > Project: Solr > Issue Type: New Feature >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Blocker > Attachments: SOLR-4725.patch > > > Making this a blocker so we resolve it. Should be quick to code if we have > consensus, maybe nothing at all to do here. > I'm not too happy with the fact that the new core discovery process has two > real gotcha's. The individual core.properties file can define 'name' and > 'dataDir'. It seems too easy to either use the same name for two different > cores or use the same dataDir, just copy the core.properties file around and > fail to edit one them. In large installations this could be a bear to track > down. > Straw-man proposal is the we remove support for them both in discovery mode. > The name defaults to the directory in which core.properties is found and the > data dir is immediately below there. > Currently, there are checks to fail to load either core if either 'name' or > 'dataDir' is defined in more than one core. I think the error reporting is > weak, you probably have to look in the log file and there should be a way to > get this in the admin UI at least. > Maybe the right thing to do is just leave it as-is and emphasize that > specifying the dataDir and name is expert level and you have to get it right, > but I wanted to get wider exposure to the problem before we push 4.3 out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4725) Should we stop supporting "name" and "dataDir" in the autodiscover mode?
[ https://issues.apache.org/jira/browse/SOLR-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634401#comment-13634401 ] Mark Miller commented on SOLR-4725: --- bq. 1> in coreContainer, do we really want to default persistence to true if it's not present? (about line 460)? No, I was more curious than anything and missed dropping the change - I think we do would want to do that, but we don't want to change that behavior for hte old style now. I'll remove that change. bq 2 It's up to you - your argument makes sense to me. I'll remove 1 and commit and lets push on from there. > Should we stop supporting "name" and "dataDir" in the autodiscover mode? > > > Key: SOLR-4725 > URL: https://issues.apache.org/jira/browse/SOLR-4725 > Project: Solr > Issue Type: New Feature >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Blocker > Attachments: SOLR-4725.patch > > > Making this a blocker so we resolve it. Should be quick to code if we have > consensus, maybe nothing at all to do here. > I'm not too happy with the fact that the new core discovery process has two > real gotcha's. The individual core.properties file can define 'name' and > 'dataDir'. It seems too easy to either use the same name for two different > cores or use the same dataDir, just copy the core.properties file around and > fail to edit one them. In large installations this could be a bear to track > down. > Straw-man proposal is the we remove support for them both in discovery mode. > The name defaults to the directory in which core.properties is found and the > data dir is immediately below there. > Currently, there are checks to fail to load either core if either 'name' or > 'dataDir' is defined in more than one core. I think the error reporting is > weak, you probably have to look in the log file and there should be a way to > get this in the admin UI at least. > Maybe the right thing to do is just leave it as-is and emphasize that > specifying the dataDir and name is expert level and you have to get it right, > but I wanted to get wider exposure to the problem before we push 4.3 out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-4661) Index Version & Gen look out of sync in replication UI when master searcher uses older commit then what is replicatable
[
https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey reassigned SOLR-4661:
--
Assignee: (was: Shawn Heisey)
That assignment was done accidentally with keyboard shortcuts. I tried to load
a new URL in the Firefox tab by pressing Ctrl-L and typing the domain name, but
apparently Jira's keyboard shortcuts take precedence over the browser.
> Index Version & Gen look out of sync in replication UI when master searcher
> uses older commit then what is replicatable
> ---
>
> Key: SOLR-4661
> URL: https://issues.apache.org/jira/browse/SOLR-4661
> Project: Solr
> Issue Type: Bug
> Components: replication (java), web gui
>Affects Versions: 4.2
> Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7
>Reporter: Aditya
> Labels: gui, replication, web
> Attachments: hoss_test.zip, IndexVersionSyncIssue.jpg,
> SOLR-4661.patch, SOLR-4661.patch, SOLR-4661.patch
>
>
> the ReplicationHandler (and the replication admin UI screen) report the index
> version & gen for the master based on what commit point is currently open for
> searching -- but this is not necessarily the most recent commit point
> available for replication.
> Thus, it can appear that a slave has "gotten ahead" of the master, if there
> are "empty commits" (because of reader reopening shotcuts) or commits using
> openSearcher=false.
> We need to add additional data to help make it clear there is no actual
> problem in this sitation.
> Summary of original bug report..
> {panel}
> Index and Gen number on Slave is higher than master.
> If you apply commit on master with no pending docs then the commit time stamp
> and gen is incremented. When Slaves polls master for replication it see the
> index version difference and starts replicating but all files are skipped.
> On Admin UI (on Slaves) the version number displayed for master is old where
> as for slave is the latest which is higher than master.
> Below is the response from master (/replication?command=details) where i see
> two different Version an Gen numbers. This creates confusion of having
> version out of sync, though its not.
> ...
> {panel}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4725) Should we stop supporting "name" and "dataDir" in the autodiscover mode?
[ https://issues.apache.org/jira/browse/SOLR-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634381#comment-13634381 ] Erick Erickson commented on SOLR-4725: -- Well, I'll just close 4725 after this gets checked in, I duplicated what you did. You chose much better names for some of the methods, insureFail was a really stupid name... I do have two questions though: 1> in coreContainer, do we really want to default persistence to true if it's not present? (about line 460)? 2> ConfigSolr.addCore[475 or so], I was thinking of removing the failure case and just logging a warning for two cores having the same name on the theory that changing this behavior in old-style solr.xml (which this case is) might be too risky at this point. We can just let it die a natural death when we stop supporting the old-style solr.xml. I don't have strong feelings one way or the other though. OK, I have to leave in 1/2 hour. I'll check in first thing in the morning, let me know if there's anything I should be doing here or if you've checked it all in. > Should we stop supporting "name" and "dataDir" in the autodiscover mode? > > > Key: SOLR-4725 > URL: https://issues.apache.org/jira/browse/SOLR-4725 > Project: Solr > Issue Type: New Feature >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Blocker > Attachments: SOLR-4725.patch > > > Making this a blocker so we resolve it. Should be quick to code if we have > consensus, maybe nothing at all to do here. > I'm not too happy with the fact that the new core discovery process has two > real gotcha's. The individual core.properties file can define 'name' and > 'dataDir'. It seems too easy to either use the same name for two different > cores or use the same dataDir, just copy the core.properties file around and > fail to edit one them. In large installations this could be a bear to track > down. > Straw-man proposal is the we remove support for them both in discovery mode. > The name defaults to the directory in which core.properties is found and the > data dir is immediately below there. > Currently, there are checks to fail to load either core if either 'name' or > 'dataDir' is defined in more than one core. I think the error reporting is > weak, you probably have to look in the log file and there should be a way to > get this in the admin UI at least. > Maybe the right thing to do is just leave it as-is and emphasize that > specifying the dataDir and name is expert level and you have to get it right, > but I wanted to get wider exposure to the problem before we push 4.3 out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-ea-b84) - Build # 5215 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/5215/ Java: 32bit/jdk1.8.0-ea-b84 -client -XX:+UseG1GC 1 tests failed. REGRESSION: org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSearch Error Message: Server at http://127.0.0.1:37980/onenodecollectioncore returned non ok status:404, message:Can not find: /onenodecollectioncore/update Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Server at http://127.0.0.1:37980/onenodecollectioncore returned non ok status:404, message:Can not find: /onenodecollectioncore/update at __randomizedtesting.SeedInfo.seed([DE79C32F73E20E92:5F9F4D3704BD6EAE]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:374) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:117) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:116) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:102) at org.apache.solr.cloud.BasicDistributedZk2Test.testNodeWithoutCollectionForwarding(BasicDistributedZk2Test.java:197) at org.apache.solr.cloud.BasicDistributedZk2Test.doTest(BasicDistributedZk2Test.java:89) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:806) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:487) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[jira] [Assigned] (SOLR-4661) Index Version & Gen look out of sync in replication UI when master searcher uses older commit then what is replicatable
[
https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey reassigned SOLR-4661:
--
Assignee: Shawn Heisey
> Index Version & Gen look out of sync in replication UI when master searcher
> uses older commit then what is replicatable
> ---
>
> Key: SOLR-4661
> URL: https://issues.apache.org/jira/browse/SOLR-4661
> Project: Solr
> Issue Type: Bug
> Components: replication (java), web gui
>Affects Versions: 4.2
> Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7
>Reporter: Aditya
>Assignee: Shawn Heisey
> Labels: gui, replication, web
> Attachments: hoss_test.zip, IndexVersionSyncIssue.jpg,
> SOLR-4661.patch, SOLR-4661.patch, SOLR-4661.patch
>
>
> the ReplicationHandler (and the replication admin UI screen) report the index
> version & gen for the master based on what commit point is currently open for
> searching -- but this is not necessarily the most recent commit point
> available for replication.
> Thus, it can appear that a slave has "gotten ahead" of the master, if there
> are "empty commits" (because of reader reopening shotcuts) or commits using
> openSearcher=false.
> We need to add additional data to help make it clear there is no actual
> problem in this sitation.
> Summary of original bug report..
> {panel}
> Index and Gen number on Slave is higher than master.
> If you apply commit on master with no pending docs then the commit time stamp
> and gen is incremented. When Slaves polls master for replication it see the
> index version difference and starts replicating but all files are skipped.
> On Admin UI (on Slaves) the version number displayed for master is old where
> as for slave is the latest which is higher than master.
> Below is the response from master (/replication?command=details) where i see
> two different Version an Gen numbers. This creates confusion of having
> version out of sync, though its not.
> ...
> {panel}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4661) Index Version & Gen look out of sync in replication UI when master searcher uses older commit then what is replicatable
[
https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634372#comment-13634372
]
Hoss Man commented on SOLR-4661:
Joel: please note my earlier comments...
bq. I did some more experimenting and confirmed i was wrong about this – from
Solr's perspective a new searcher is definitely getting opened and warmed.
...you can clearly see in the logs that an "empty" commit causes a new Searcher
to be opened in any situation -- but when it happens on the master the
underlying call to "DirectoryReader.openIfChanged" recognizes that the commit
point in the directory is identical. On the slave side it may not recognize
this because the physical directory itself can change (ie: index vs
index.)
Even if there is a bug here (or room for optimization on the slave side) we
should track it separately since the crux of thies issue (the UI is comparing
apples and oranges) would still be true -- notably in the case where someone
may do an openSearcher=false commit on the master, creating a new replicable
version for slaves w/o opening a new searcher on the master.
> Index Version & Gen look out of sync in replication UI when master searcher
> uses older commit then what is replicatable
> ---
>
> Key: SOLR-4661
> URL: https://issues.apache.org/jira/browse/SOLR-4661
> Project: Solr
> Issue Type: Bug
> Components: replication (java), web gui
>Affects Versions: 4.2
> Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7
>Reporter: Aditya
> Labels: gui, replication, web
> Attachments: hoss_test.zip, IndexVersionSyncIssue.jpg,
> SOLR-4661.patch, SOLR-4661.patch, SOLR-4661.patch
>
>
> the ReplicationHandler (and the replication admin UI screen) report the index
> version & gen for the master based on what commit point is currently open for
> searching -- but this is not necessarily the most recent commit point
> available for replication.
> Thus, it can appear that a slave has "gotten ahead" of the master, if there
> are "empty commits" (because of reader reopening shotcuts) or commits using
> openSearcher=false.
> We need to add additional data to help make it clear there is no actual
> problem in this sitation.
> Summary of original bug report..
> {panel}
> Index and Gen number on Slave is higher than master.
> If you apply commit on master with no pending docs then the commit time stamp
> and gen is incremented. When Slaves polls master for replication it see the
> index version difference and starts replicating but all files are skipped.
> On Admin UI (on Slaves) the version number displayed for master is old where
> as for slave is the latest which is higher than master.
> Below is the response from master (/replication?command=details) where i see
> two different Version an Gen numbers. This creates confusion of having
> version out of sync, though its not.
> ...
> {panel}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release PyLucene 4.2.1
On Tue, 16 Apr 2013, Chris Hostetter wrote:
: A release candidate is available from:
: http://people.apache.org/~vajda/staging_area/
-1 to releasing the files with the following MD5 checksums...
c84b71c718cee06bff63d5757115aa71 pylucene-4.2.1-0-src.tar.gz
a49300178884804ba9f7438a19732b21 pylucene-4.2.1-0-src.tar.gz.asc
f9d4c51dc4a04fc65d7630c8c8371be5 pylucene-4.2.1-0-src.tar.gz.md5
Problems encountered...
1) pylucene-4.2.1-0-src.tar.gz.md5 is not formated such that it can be
easily verified using "md5sum -c" (refers to "stdin")
Fixed, using md5sum to generate checksum now.
2) NOTICE file does not correctly reflect year of the distribution (2009
instead of 2013)
Fixed.
3) INSTALL and README files that refer to files in "doc/documentation"
however there is no "doc" directory, and the file names refered to
("readme.html" and "install.html") do not exist in any directory.
Removed the reference to the no longer existing docs directory and edited
side to no longer refer to now obsolete (and removed) Lucene in Action
samples.
4) Attempting to "make" the project resulted in an immediate build failure
w/o a clear indication of what the problem was...
hossman@frisbee:~/tmp/pylucene_4_2_1_rc/pylucene-4.2.1-0$ make
cd lucene-java-4.2.1/lucene; ( ivy-fail || ivy-bootstrap)
/bin/sh: 1: ivy-fail: not found
/bin/sh: 1: ivy-bootstrap: not found
make: *** [ivy] Error 127
(based on the install.html from the pylucene website, i'm guessing this is
related to not manually editing the Makefile, or specifying some mandatory
variables to 'make' on the commandline, but it seems wrong not to have a
more straight forward error here if that is what's required.)
Fixed by adding error messages complaining about the missing env var(s).
Andi..
Re: svn commit: r1469040 - /lucene/dev/branches/branch_4x/dev-tools/scripts/buildAndPushRelease.py
WOOT
On Wed, Apr 17, 2013 at 9:33 PM, wrote:
> Author: mikemccand
> Date: Wed Apr 17 19:33:48 2013
> New Revision: 1469040
>
> URL: http://svn.apache.org/r1469040
> Log:
> prompt for GPG password up front
>
> Modified:
> lucene/dev/branches/branch_4x/dev-tools/scripts/buildAndPushRelease.py
>
> Modified:
> lucene/dev/branches/branch_4x/dev-tools/scripts/buildAndPushRelease.py
> URL:
> http://svn.apache.org/viewvc/lucene/dev/branches/branch_4x/dev-tools/scripts/buildAndPushRelease.py?rev=1469040&r1=1469039&r2=1469040&view=diff
>
> ==
> --- lucene/dev/branches/branch_4x/dev-tools/scripts/buildAndPushRelease.py
> (original)
> +++ lucene/dev/branches/branch_4x/dev-tools/scripts/buildAndPushRelease.py
> Wed Apr 17 19:33:48 2013
> @@ -15,9 +15,11 @@
>
> import datetime
> import re
> +import time
> import shutil
> import os
> import sys
> +import subprocess
>
> # Usage: python3.2 -u buildAndPushRelease.py [-sign gpgKey(eg: 6E68DA61)]
> [-prepare] [-push userName] [-pushLocal dirName] [-smoke tmpDir]
> /path/to/checkout version(eg: 3.4.0) rcNum(eg: 0)
> #
> @@ -43,6 +45,25 @@ def run(command):
> print(msg)
> raise RuntimeError(msg)
>
> +def runAndSendGPGPassword(command, password):
> + p = subprocess.Popen(command, shell=True, stdout=subprocess.PIPE,
> stderr=subprocess.STDOUT, stdin=subprocess.PIPE)
> + f = open(LOG, 'ab')
> + while True:
> +line = p.stdout.readline()
> +if len(line) == 0:
> + break
> +f.write(line)
> +if line.find(b'Enter GPG keystore password:') != -1:
> + time.sleep(1.0)
> + p.stdin.write((password + '\n').encode('UTF-8'))
> + p.stdin.write('\n'.encode('UTF-8'))
> +
> + result = p.poll()
> + if result != 0:
> +msg = 'FAILED: %s [see log %s]' % (command, LOG)
> +print(msg)
> +raise RuntimeError(msg)
> +
> def scrubCheckout():
># removes any files not checked into svn
>
> @@ -68,7 +89,7 @@ def getSVNRev():
>return rev
>
>
> -def prepare(root, version, gpgKeyID, doTest):
> +def prepare(root, version, gpgKeyID, gpgPassword, doTest):
>print()
>print('Prepare release...')
>if os.path.exists(LOG):
> @@ -98,7 +119,11 @@ def prepare(root, version, gpgKeyID, doT
> cmd += ' -Dgpg.key=%s prepare-release' % gpgKeyID
>else:
> cmd += ' prepare-release-no-sign'
> - run(cmd)
> +
> + if gpgPassword is not None:
> +runAndSendGPGPassword(cmd, gpgPassword)
> + else:
> +run(cmd)
>
>print(' solr prepare-release')
>os.chdir('../solr')
> @@ -107,7 +132,12 @@ def prepare(root, version, gpgKeyID, doT
> cmd += ' -Dgpg.key=%s prepare-release' % gpgKeyID
>else:
> cmd += ' prepare-release-no-sign'
> - run(cmd)
> +
> + if gpgPassword is not None:
> +runAndSendGPGPassword(cmd, gpgPassword)
> + else:
> +run(cmd)
> +
>print(' done!')
>print()
>return rev
> @@ -253,12 +283,16 @@ def main():
> gpgKeyID = sys.argv[idx+1]
> del sys.argv[idx:idx+2]
>
> +sys.stdout.flush()
> +import getpass
> +gpgPassword = getpass.getpass('Enter GPG keystore password: ')
> +
>root = os.path.abspath(sys.argv[1])
>version = sys.argv[2]
>rcNum = int(sys.argv[3])
>
>if doPrepare:
> -rev = prepare(root, version, gpgKeyID, smokeTmpDir is None)
> +rev = prepare(root, version, gpgKeyID, gpgPassword, smokeTmpDir is
> None)
>else:
> os.chdir(root)
> rev = open('rev.txt', encoding='UTF-8').read()
>
>
>
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_17) - Build # 5212 - Failure!
you merge to 4x as usual and then you merge the fix to lucene_solr_4_3 as
well. you place the Changes notice already in the 4.3 section when you
commit to trunk.
simon
On Wed, Apr 17, 2013 at 9:53 PM, Erick Erickson wrote:
> Simon:
>
> I want to be sure I don't mess this up, and never having been a RM I'm
> not all that familiar with the process. When you say "roll another
> release" will you merge 4x or do I need to merge any changes I need in
> 4.3 into lucene_solr_4_3 as well as 4x?
>
> Thanks,
> Erick
>
> On Wed, Apr 17, 2013 at 3:24 PM, Robert Muir wrote:
> > cool, i opened https://issues.apache.org/jira/browse/LUCENE-4938
> >
> > We should still have explicit tests for this, and there is still the
> mystery
> > of how this test ever passed at all!
> >
> >
> > On Wed, Apr 17, 2013 at 12:18 PM, Simon Willnauer
> > wrote:
> >>
> >> @rob you can add the fix too if you want that is fine I will roll
> another
> >> release anyways
> >>
> >> simon
> >>
> >>
> >> On Wed, Apr 17, 2013 at 9:14 PM, Robert Muir wrote:
> >>>
> >>> I'll open an issue. We should at least fix the test for 4.3 if possible
> >>> (the indexsearcher change can wait)
> >>>
> >>>
> >>> On Wed, Apr 17, 2013 at 9:19 AM, Robert Muir wrote:
>
> I see the bug (two bugs).
>
> One bug is the test does IndexSearcher.search(query,
> Integer.MAX_VALUE,
> sort)
>
> In the case of search-without-sort, there is some code that
> essentially
> does Math.min(maxdoc, ndoc) so that if you request more documents than
> actually exist in the index, we create a smaller priority queue. I
> think Uwe
> added that not so long ago. But this code isn't in search-with-sort...
> Index:
> lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
> ===
> --- lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
> (revision 1468947)
> +++ lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
> (working copy)
> @@ -511,6 +511,12 @@
>
> if (sort == null) throw new NullPointerException("Sort must not
> be
> null");
>
> +int limit = reader.maxDoc();
> +if (limit == 0) {
> + limit = 1;
> +}
> +nDocs = Math.min(nDocs, limit);
> +
> if (executor == null) {
> // use all leaves here!
> return search(leafContexts, weight, after, nDocs, sort,
> fillFields, doDocScores, doMaxScore);
> Index:
>
> lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
> ===
> ---
>
> lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
> (revision 1468947)
> +++
>
> lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
> (working copy)
> @@ -69,7 +69,7 @@
>
> // Get hits sorted by our FunctionValues (ascending values)
> Query q = new MatchAllDocsQuery();
> -TopDocs hits = searcher.search(q, Integer.MAX_VALUE, orderBy);
> +TopDocs hits = searcher.search(q, reader.maxDoc(), orderBy);
> assertEquals(NUM_VALS, hits.scoreDocs.length);
> // Verify that sorting works in general
> int i = 0;
> @@ -81,7 +81,7 @@
> // Now get hits after hit #2 using IS.searchAfter()
> int afterIdx = 1;
> FieldDoc afterHit = (FieldDoc) hits.scoreDocs[afterIdx];
> -hits = searcher.searchAfter(afterHit, q, Integer.MAX_VALUE,
> orderBy);
> +hits = searcher.searchAfter(afterHit, q, reader.maxDoc(),
> orderBy);
>
> // Expected # of hits: NUM_VALS - 2
> assertEquals(NUM_VALS - (afterIdx + 1), hits.scoreDocs.length);
>
>
> On Wed, Apr 17, 2013 at 10:54 AM, Policeman Jenkins Server
> wrote:
> >
> > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/5212/
> > Java: 32bit/jdk1.7.0_17 -client -XX:+UseG1GC
> >
> > 1 tests failed.
> > REGRESSION:
> >
> org.apache.lucene.queries.function.TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues
> >
> > Error Message:
> > Requested array size exceeds VM limit
> >
> > Stack Trace:
> > java.lang.OutOfMemoryError: Requested array size exceeds VM limit
> > at
> >
> __randomizedtesting.SeedInfo.seed([19CBB97056276D92:E7ABF8B5EEE0EA22]:0)
> > at
> > org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:64)
> > at
> > org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:37)
> > at
> >
> org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:138)
> > at
> >
> org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:34)
> > at
> >
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_17) - Build # 5212 - Failure!
Simon:
I want to be sure I don't mess this up, and never having been a RM I'm
not all that familiar with the process. When you say "roll another
release" will you merge 4x or do I need to merge any changes I need in
4.3 into lucene_solr_4_3 as well as 4x?
Thanks,
Erick
On Wed, Apr 17, 2013 at 3:24 PM, Robert Muir wrote:
> cool, i opened https://issues.apache.org/jira/browse/LUCENE-4938
>
> We should still have explicit tests for this, and there is still the mystery
> of how this test ever passed at all!
>
>
> On Wed, Apr 17, 2013 at 12:18 PM, Simon Willnauer
> wrote:
>>
>> @rob you can add the fix too if you want that is fine I will roll another
>> release anyways
>>
>> simon
>>
>>
>> On Wed, Apr 17, 2013 at 9:14 PM, Robert Muir wrote:
>>>
>>> I'll open an issue. We should at least fix the test for 4.3 if possible
>>> (the indexsearcher change can wait)
>>>
>>>
>>> On Wed, Apr 17, 2013 at 9:19 AM, Robert Muir wrote:
I see the bug (two bugs).
One bug is the test does IndexSearcher.search(query, Integer.MAX_VALUE,
sort)
In the case of search-without-sort, there is some code that essentially
does Math.min(maxdoc, ndoc) so that if you request more documents than
actually exist in the index, we create a smaller priority queue. I think
Uwe
added that not so long ago. But this code isn't in search-with-sort...
Index: lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
===
--- lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
(revision 1468947)
+++ lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
(working copy)
@@ -511,6 +511,12 @@
if (sort == null) throw new NullPointerException("Sort must not be
null");
+int limit = reader.maxDoc();
+if (limit == 0) {
+ limit = 1;
+}
+nDocs = Math.min(nDocs, limit);
+
if (executor == null) {
// use all leaves here!
return search(leafContexts, weight, after, nDocs, sort,
fillFields, doDocScores, doMaxScore);
Index:
lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
===
---
lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
(revision 1468947)
+++
lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
(working copy)
@@ -69,7 +69,7 @@
// Get hits sorted by our FunctionValues (ascending values)
Query q = new MatchAllDocsQuery();
-TopDocs hits = searcher.search(q, Integer.MAX_VALUE, orderBy);
+TopDocs hits = searcher.search(q, reader.maxDoc(), orderBy);
assertEquals(NUM_VALS, hits.scoreDocs.length);
// Verify that sorting works in general
int i = 0;
@@ -81,7 +81,7 @@
// Now get hits after hit #2 using IS.searchAfter()
int afterIdx = 1;
FieldDoc afterHit = (FieldDoc) hits.scoreDocs[afterIdx];
-hits = searcher.searchAfter(afterHit, q, Integer.MAX_VALUE,
orderBy);
+hits = searcher.searchAfter(afterHit, q, reader.maxDoc(), orderBy);
// Expected # of hits: NUM_VALS - 2
assertEquals(NUM_VALS - (afterIdx + 1), hits.scoreDocs.length);
On Wed, Apr 17, 2013 at 10:54 AM, Policeman Jenkins Server
wrote:
>
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/5212/
> Java: 32bit/jdk1.7.0_17 -client -XX:+UseG1GC
>
> 1 tests failed.
> REGRESSION:
> org.apache.lucene.queries.function.TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues
>
> Error Message:
> Requested array size exceeds VM limit
>
> Stack Trace:
> java.lang.OutOfMemoryError: Requested array size exceeds VM limit
> at
> __randomizedtesting.SeedInfo.seed([19CBB97056276D92:E7ABF8B5EEE0EA22]:0)
> at
> org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:64)
> at
> org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:37)
> at
> org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:138)
> at
> org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:34)
> at
> org.apache.lucene.search.FieldValueHitQueue$OneComparatorFieldValueHitQueue.(FieldValueHitQueue.java:63)
> at
> org.apache.lucene.search.FieldValueHitQueue.create(FieldValueHitQueue.java:171)
> at
> org.apache.lucene.search.TopFieldCollector.create(TopFieldCollector.java:1123)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:518)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java
[jira] [Resolved] (SOLR-4714) Solr server request handler failed
[ https://issues.apache.org/jira/browse/SOLR-4714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-4714. Resolution: Invalid There's really not enough detail here to indicate a Solr problem. It sounds like you are exceeding the limits allowed according to your Servlet Containers settings -- either for the POST body, or for the URL. google searchers for "HttpParser Full" suggest that this error is coming from jetty related to how long the request URL is -- you mentioned you were doing an HTTP POST, but w/o any specific code, i suspect that you are still including your query as URL params when doing that POST. If you are still having problems, please send an email with more details (ie: servlet container used, example of your request code, details of th server respnose, details of the log messages recorded, etc...) to the solr-user@lucene mailing list. There is no need to re-open this bug unless someone confirms there is a particular problem with solr. > Solr server request handler failed > -- > > Key: SOLR-4714 > URL: https://issues.apache.org/jira/browse/SOLR-4714 > Project: Solr > Issue Type: Bug >Reporter: Hardik Upadhyay > Labels: solr > > When sending a search request via HttpClient post method,solr server fails to > parse the query and prints error "HttpParser full". > The search request was for retrieving 600 entity details ,q:(ent1 ent2 ent3 > ... ent600) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-MacOSX ([[ Exception while replacing ENV. Please report this as a bug. ]]
{{ java.lang.NullPointerException }}) -
Build # 389 - Failure!
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="=_Part_0_316637105.1366227395613"
X-Jenkins-Job: Lucene-Solr-4.x-MacOSX
X-Jenkins-Result: FAILURE
Precedence: bulk
--=_Part_0_316637105.1366227395613
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/389/
Java: [[ Exception while replacing ENV. Please report this as a bug. ]]
{{ java.lang.NullPointerException }}
No tests ran.
Build Log:
[...truncated 1272 lines...]
FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected
reader termination
[junit4:junit4] Completed in 0.11s, 1 test
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.document.TestField
[junit4:junit4] Completed in 0.20s, 19 tests
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.search.TestDateSort
[junit4:junit4] Completed in 0.12s, 1 test
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.search.TestSimilarity
[junit4:junit4] Completed in 0.06s, 1 test
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.util.TestIdentityHashSet
[junit4:junit4] Completed in 0.27s, 1 test
[junit4:junit4]
[junit4:junit4] Suite:
org.apache.lucene.search.spans.TestSpanExplanationsOfNonMatches
[junit4:junit4] Completed in 0.33s, 31 tests
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.util.TestSmallFloat
[junit4:junit4] Completed in 0.20s, 2 tests
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.search.TestSimilarityProvider
[junit4:junit4] Completed in 0.07s, 1 test
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.util.TestSetOnce
[junit4:junit4] Completed in 0.12s, 4 tests
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.index.TestFilterAtomicReader
[junit4:junit4] Completed in 0.10s, 2 tests
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.TestSearch
[junit4:junit4] Completed in 0.21s, 2 tests
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.analysis.TestCachingTokenFilter
[junit4:junit4] Completed in 0.08s, 1 test
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestSeedFromUncaught
[junit4:junit4] Completed in 0.07s, 1 test
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.search.TestDateFilter
[junit4:junit4] Completed in 0.07s, 2 tests
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.index.Test2BPostings
[junit4:junit4] IGNOR/A 0.00s | Test2BPostings.test
[junit4:junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] Completed in 0.05s, 1 test, 1 skipped
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.index.TestSameTokenSamePosition
[junit4:junit4] Completed in 0.15s, 2 tests
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.document.TestBinaryDocument
[junit4:junit4] Completed in 0.16s, 2 tests
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.search.TestAutomatonQueryUnicode
[junit4:junit4] Completed in 0.07s, 1 test
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.util.TestAttributeSource
[junit4:junit4] Completed in 0.06s, 5 tests
[junit4:junit4]
[junit4:junit4] Suite:
org.apache.lucene.util.junitcompat.TestFailOnFieldCacheInsanity
[junit4:junit4] Completed in 0.07s, 1 test
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.search.TestTotalHitCountCollector
[junit4:junit4] Completed in 0.06s, 1 test
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.util.TestRecyclingByteBlockAllocator
[junit4:junit4] Completed in 0.11s, 3 tests
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.store.TestLock
[junit4:junit4] Completed in 0.05s, 1 test
[junit4:junit4]
[junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpanFirstQuery
hudson.remoting.RequestAbortedException:
hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected reader
termination
at hudson.remoting.Request.call(Request.java:174)
at hudson.remoting.Channel.call(Channel.java:672)
at
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158)
at com.sun.proxy.$Proxy72.join(Unknown Source)
at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:915)
at hudson.Launcher$ProcStarter.join(Launcher.java:360)
at hudson.tasks.Ant.perform(Ant.java:217)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:802)
at hudson.model.Build$BuildExecution.build(Build.java:199)
at hudson.model.Build$BuildExecution.doRun(Build.java:160)
at
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:584)
at hudson.model.Run.execute(Run.java:1575)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at
[jira] [Updated] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-4662: -- Attachment: SOLR-4662.patch Here is a patch from my first quick review of this - it fixes a few mostly minor issues. This is great work overall Erick! This fixes an issue with the core admin path on 5x, an issue with setting the right instance dir when using alternate core discovery locations, and some other minor nits. I plan to commit this very shortly so that Erick can merge his work in and then take a deeper dive through the evening. > Finalize what we're going to do with solr.xml, auto-discovery, config sets. > --- > > Key: SOLR-4662 > URL: https://issues.apache.org/jira/browse/SOLR-4662 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Mark Miller >Priority: Blocker > Attachments: SOLR-4662.patch, SOLR-4662.patch, SOLR-4662.patch, > SOLR-4662.patch, SOLR-4662.patch > > > Spinoff from SOLR-4615, breaking it out here so we can address the changes in > pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_17) - Build # 5212 - Failure!
cool, i opened https://issues.apache.org/jira/browse/LUCENE-4938
We should still have explicit tests for this, and there is still the
mystery of how this test ever passed at all!
On Wed, Apr 17, 2013 at 12:18 PM, Simon Willnauer wrote:
> @rob you can add the fix too if you want that is fine I will roll another
> release anyways
>
> simon
>
>
> On Wed, Apr 17, 2013 at 9:14 PM, Robert Muir wrote:
>
>> I'll open an issue. We should at least fix the test for 4.3 if possible
>> (the indexsearcher change can wait)
>>
>>
>> On Wed, Apr 17, 2013 at 9:19 AM, Robert Muir wrote:
>>
>>> I see the bug (two bugs).
>>>
>>> One bug is the test does IndexSearcher.search(query, Integer.MAX_VALUE,
>>> sort)
>>>
>>> In the case of search-without-sort, there is some code that essentially
>>> does Math.min(maxdoc, ndoc) so that if you request more documents than
>>> actually exist in the index, we create a smaller priority queue. I think
>>> Uwe added that not so long ago. But this code isn't in search-with-sort...
>>> Index: lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
>>> ===
>>> --- lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
>>> (revision 1468947)
>>> +++ lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
>>> (working copy)
>>> @@ -511,6 +511,12 @@
>>>
>>> if (sort == null) throw new NullPointerException("Sort must not be
>>> null");
>>>
>>> +int limit = reader.maxDoc();
>>> +if (limit == 0) {
>>> + limit = 1;
>>> +}
>>> +nDocs = Math.min(nDocs, limit);
>>> +
>>> if (executor == null) {
>>>// use all leaves here!
>>>return search(leafContexts, weight, after, nDocs, sort,
>>> fillFields, doDocScores, doMaxScore);
>>> Index:
>>> lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
>>> ===
>>> ---
>>> lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
>>> (revision 1468947)
>>> +++
>>> lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
>>> (working copy)
>>> @@ -69,7 +69,7 @@
>>>
>>> // Get hits sorted by our FunctionValues (ascending values)
>>> Query q = new MatchAllDocsQuery();
>>> -TopDocs hits = searcher.search(q, Integer.MAX_VALUE, orderBy);
>>> +TopDocs hits = searcher.search(q, reader.maxDoc(), orderBy);
>>> assertEquals(NUM_VALS, hits.scoreDocs.length);
>>> // Verify that sorting works in general
>>> int i = 0;
>>> @@ -81,7 +81,7 @@
>>> // Now get hits after hit #2 using IS.searchAfter()
>>> int afterIdx = 1;
>>> FieldDoc afterHit = (FieldDoc) hits.scoreDocs[afterIdx];
>>> -hits = searcher.searchAfter(afterHit, q, Integer.MAX_VALUE,
>>> orderBy);
>>> +hits = searcher.searchAfter(afterHit, q, reader.maxDoc(), orderBy);
>>>
>>> // Expected # of hits: NUM_VALS - 2
>>> assertEquals(NUM_VALS - (afterIdx + 1), hits.scoreDocs.length);
>>>
>>>
>>> On Wed, Apr 17, 2013 at 10:54 AM, Policeman Jenkins Server <
>>> jenk...@thetaphi.de> wrote:
>>>
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/5212/
Java: 32bit/jdk1.7.0_17 -client -XX:+UseG1GC
1 tests failed.
REGRESSION:
org.apache.lucene.queries.function.TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues
Error Message:
Requested array size exceeds VM limit
Stack Trace:
java.lang.OutOfMemoryError: Requested array size exceeds VM limit
at
__randomizedtesting.SeedInfo.seed([19CBB97056276D92:E7ABF8B5EEE0EA22]:0)
at
org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:64)
at
org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:37)
at
org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:138)
at
org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:34)
at
org.apache.lucene.search.FieldValueHitQueue$OneComparatorFieldValueHitQueue.(FieldValueHitQueue.java:63)
at
org.apache.lucene.search.FieldValueHitQueue.create(FieldValueHitQueue.java:171)
at
org.apache.lucene.search.TopFieldCollector.create(TopFieldCollector.java:1123)
at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:518)
at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:493)
at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:370)
at
org.apache.lucene.queries.function.TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues(TestFunctionQuerySort.java:72)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[jira] [Updated] (LUCENE-4938) IndexSearcher.search() with sort doesnt do min(maxdoc, n)
[ https://issues.apache.org/jira/browse/LUCENE-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4938: Attachment: LUCENE-4938.patch This is the patch i sent to the dev list. But we should add simple tests for this (also for the other search method). Also i want to know how the test ever passed... is this due to something AssertingIndexSearcher is doing? > IndexSearcher.search() with sort doesnt do min(maxdoc, n) > - > > Key: LUCENE-4938 > URL: https://issues.apache.org/jira/browse/LUCENE-4938 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-4938.patch > > > It does this without a sort though. > This caused TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues > to OOM (why only sometimes?) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_17) - Build # 5212 - Failure!
@rob you can add the fix too if you want that is fine I will roll another
release anyways
simon
On Wed, Apr 17, 2013 at 9:14 PM, Robert Muir wrote:
> I'll open an issue. We should at least fix the test for 4.3 if possible
> (the indexsearcher change can wait)
>
>
> On Wed, Apr 17, 2013 at 9:19 AM, Robert Muir wrote:
>
>> I see the bug (two bugs).
>>
>> One bug is the test does IndexSearcher.search(query, Integer.MAX_VALUE,
>> sort)
>>
>> In the case of search-without-sort, there is some code that essentially
>> does Math.min(maxdoc, ndoc) so that if you request more documents than
>> actually exist in the index, we create a smaller priority queue. I think
>> Uwe added that not so long ago. But this code isn't in search-with-sort...
>> Index: lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
>> ===
>> --- lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
>> (revision 1468947)
>> +++ lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
>> (working copy)
>> @@ -511,6 +511,12 @@
>>
>> if (sort == null) throw new NullPointerException("Sort must not be
>> null");
>>
>> +int limit = reader.maxDoc();
>> +if (limit == 0) {
>> + limit = 1;
>> +}
>> +nDocs = Math.min(nDocs, limit);
>> +
>> if (executor == null) {
>>// use all leaves here!
>>return search(leafContexts, weight, after, nDocs, sort,
>> fillFields, doDocScores, doMaxScore);
>> Index:
>> lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
>> ===
>> ---
>> lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
>> (revision 1468947)
>> +++
>> lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
>> (working copy)
>> @@ -69,7 +69,7 @@
>>
>> // Get hits sorted by our FunctionValues (ascending values)
>> Query q = new MatchAllDocsQuery();
>> -TopDocs hits = searcher.search(q, Integer.MAX_VALUE, orderBy);
>> +TopDocs hits = searcher.search(q, reader.maxDoc(), orderBy);
>> assertEquals(NUM_VALS, hits.scoreDocs.length);
>> // Verify that sorting works in general
>> int i = 0;
>> @@ -81,7 +81,7 @@
>> // Now get hits after hit #2 using IS.searchAfter()
>> int afterIdx = 1;
>> FieldDoc afterHit = (FieldDoc) hits.scoreDocs[afterIdx];
>> -hits = searcher.searchAfter(afterHit, q, Integer.MAX_VALUE, orderBy);
>> +hits = searcher.searchAfter(afterHit, q, reader.maxDoc(), orderBy);
>>
>> // Expected # of hits: NUM_VALS - 2
>> assertEquals(NUM_VALS - (afterIdx + 1), hits.scoreDocs.length);
>>
>>
>> On Wed, Apr 17, 2013 at 10:54 AM, Policeman Jenkins Server <
>> jenk...@thetaphi.de> wrote:
>>
>>> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/5212/
>>> Java: 32bit/jdk1.7.0_17 -client -XX:+UseG1GC
>>>
>>> 1 tests failed.
>>> REGRESSION:
>>>
>>> org.apache.lucene.queries.function.TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues
>>>
>>> Error Message:
>>> Requested array size exceeds VM limit
>>>
>>> Stack Trace:
>>> java.lang.OutOfMemoryError: Requested array size exceeds VM limit
>>> at
>>> __randomizedtesting.SeedInfo.seed([19CBB97056276D92:E7ABF8B5EEE0EA22]:0)
>>> at
>>> org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:64)
>>> at
>>> org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:37)
>>> at
>>> org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:138)
>>> at
>>> org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:34)
>>> at
>>> org.apache.lucene.search.FieldValueHitQueue$OneComparatorFieldValueHitQueue.(FieldValueHitQueue.java:63)
>>> at
>>> org.apache.lucene.search.FieldValueHitQueue.create(FieldValueHitQueue.java:171)
>>> at
>>> org.apache.lucene.search.TopFieldCollector.create(TopFieldCollector.java:1123)
>>> at
>>> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:518)
>>> at
>>> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:493)
>>> at
>>> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:370)
>>> at
>>> org.apache.lucene.queries.function.TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues(TestFunctionQuerySort.java:72)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:601)
>>> at
>>> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
>>> at
>>> com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRu
[jira] [Created] (LUCENE-4938) IndexSearcher.search() with sort doesnt do min(maxdoc, n)
Robert Muir created LUCENE-4938: --- Summary: IndexSearcher.search() with sort doesnt do min(maxdoc, n) Key: LUCENE-4938 URL: https://issues.apache.org/jira/browse/LUCENE-4938 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir It does this without a sort though. This caused TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues to OOM (why only sometimes?) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_17) - Build # 5212 - Failure!
I'll open an issue. We should at least fix the test for 4.3 if possible
(the indexsearcher change can wait)
On Wed, Apr 17, 2013 at 9:19 AM, Robert Muir wrote:
> I see the bug (two bugs).
>
> One bug is the test does IndexSearcher.search(query, Integer.MAX_VALUE,
> sort)
>
> In the case of search-without-sort, there is some code that essentially
> does Math.min(maxdoc, ndoc) so that if you request more documents than
> actually exist in the index, we create a smaller priority queue. I think
> Uwe added that not so long ago. But this code isn't in search-with-sort...
> Index: lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
> ===
> --- lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
> (revision 1468947)
> +++ lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
> (working copy)
> @@ -511,6 +511,12 @@
>
> if (sort == null) throw new NullPointerException("Sort must not be
> null");
>
> +int limit = reader.maxDoc();
> +if (limit == 0) {
> + limit = 1;
> +}
> +nDocs = Math.min(nDocs, limit);
> +
> if (executor == null) {
>// use all leaves here!
>return search(leafContexts, weight, after, nDocs, sort, fillFields,
> doDocScores, doMaxScore);
> Index:
> lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
> ===
> ---
> lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
> (revision 1468947)
> +++
> lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
> (working copy)
> @@ -69,7 +69,7 @@
>
> // Get hits sorted by our FunctionValues (ascending values)
> Query q = new MatchAllDocsQuery();
> -TopDocs hits = searcher.search(q, Integer.MAX_VALUE, orderBy);
> +TopDocs hits = searcher.search(q, reader.maxDoc(), orderBy);
> assertEquals(NUM_VALS, hits.scoreDocs.length);
> // Verify that sorting works in general
> int i = 0;
> @@ -81,7 +81,7 @@
> // Now get hits after hit #2 using IS.searchAfter()
> int afterIdx = 1;
> FieldDoc afterHit = (FieldDoc) hits.scoreDocs[afterIdx];
> -hits = searcher.searchAfter(afterHit, q, Integer.MAX_VALUE, orderBy);
> +hits = searcher.searchAfter(afterHit, q, reader.maxDoc(), orderBy);
>
> // Expected # of hits: NUM_VALS - 2
> assertEquals(NUM_VALS - (afterIdx + 1), hits.scoreDocs.length);
>
>
> On Wed, Apr 17, 2013 at 10:54 AM, Policeman Jenkins Server <
> jenk...@thetaphi.de> wrote:
>
>> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/5212/
>> Java: 32bit/jdk1.7.0_17 -client -XX:+UseG1GC
>>
>> 1 tests failed.
>> REGRESSION:
>>
>> org.apache.lucene.queries.function.TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues
>>
>> Error Message:
>> Requested array size exceeds VM limit
>>
>> Stack Trace:
>> java.lang.OutOfMemoryError: Requested array size exceeds VM limit
>> at
>> __randomizedtesting.SeedInfo.seed([19CBB97056276D92:E7ABF8B5EEE0EA22]:0)
>> at
>> org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:64)
>> at
>> org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:37)
>> at
>> org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:138)
>> at
>> org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:34)
>> at
>> org.apache.lucene.search.FieldValueHitQueue$OneComparatorFieldValueHitQueue.(FieldValueHitQueue.java:63)
>> at
>> org.apache.lucene.search.FieldValueHitQueue.create(FieldValueHitQueue.java:171)
>> at
>> org.apache.lucene.search.TopFieldCollector.create(TopFieldCollector.java:1123)
>> at
>> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:518)
>> at
>> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:493)
>> at
>> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:370)
>> at
>> org.apache.lucene.queries.function.TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues(TestFunctionQuerySort.java:72)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:601)
>> at
>> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
>> at
>> com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
>> at
>> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
>> at
>> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
>> at
>> com.carrotsearch.randomized
Re: AW: [VOTE] Release PyLucene 4.2.1
On Wed, 17 Apr 2013, Thomas Koch wrote:
sorry, but -1 for Windows build:
OK: I was able to build JCC 1.16 with Python27 on Win32 (Win7).
Fail: I could not build PyLucene 4.2.1 with Python27 and Java 1.6.
After having upgraded from my old ant 1.8.0 to ant 1.9.0 (make now requires
ant 1.8.2) I could also run make (the ivy-target successfully downloaded and
installed ivy-2.3.0.jar in my C:\Users\Koch\.ant\lib dir, btw). However the
build fails with a compiler error:
error: command '"C:\Program Files\Microsoft Visual Studio
9.0\VC\BIN\cl.exe"' failed with exit status 2
make: *** [compile] Error 1
details attached - I don't actually see any syntax error (though my C++
knowledge is bit outdated) and assume it's all caused by the declaration of
max() which VC9 understands as macro (why?). Unfortunately VisualStudio
Messages are all in German - the ones about macro translate to
Collections.h(126) : warning C4003: not enough parameters provided for macro
'max'
same for min:
Collections.h(128) : warning C4003: not enough parameters provided for macro
'min'
Note: I used the same MS-VisualStudio 9 (and same machine/setup ? except of
ant) I used to build PyLucene 3.6.x before (successfully). However the
Collections seems to be new in 4.2
The lines 126-129 in java/util/Collections.h are:
static ::java::lang::Object max(const ::java::util::Collection &);
static ::java::lang::Object max(const ::java::util::Collection &,
const ::java::util::Comparator &);
static ::java::lang::Object min(const ::java::util::Collection &);
static ::java::lang::Object min(const ::java::util::Collection &,
const ::java::util::Comparator &);
Any ideas?
I see now. These come from the Java class. No renaming there.
Ok, I'll add these to the reserved words list in JCC.
Andi..
Regards,
Thomas
--
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(126) : warning C4003: Nicht genügend übergebene Parameter
für das Makro 'max'
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(126) : error C2059: Syntaxfehler: '('
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(126) : error C2059: Syntaxfehler: ')'
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(126) : error C2143: Syntaxfehler: Es fehlt ')' vor '?'
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(126) : error C2143: Syntaxfehler: Es fehlt ';' vor '?'
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(126) : error C4430: Fehlender Typspezifizierer - int wird
angenommen. Hinweis: "default-int" wird von C++ nicht unterst?tzt.
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(126) : warning C4183: 'Object': Rückgabetyp fehlt;
Memberfunktion, die 'int' zur?ckgibt wird angenommen
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(126) : error C2334: Unerwartete(s) Token vor ':';
sichtbarer Funktionstext wird ?übersprungen
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(126) : error C2760: Syntaxfehler: '{' erwartet und nicht
';'
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(127) : error C2144: Syntaxfehler: 'java::lang::Object'
sollte auf '}' folgen
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(127) : error C2059: Syntaxfehler: '('
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(127) : error C2059: Syntaxfehler: ')'
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(127) : error C2143: Syntaxfehler: Es fehlt ')' vor '?'
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(127) : error C2143: Syntaxfehler: Es fehlt ';' vor '?'
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(127) : error C4430: Fehlender Typspezifizierer - int wird
angenommen. Hinweis: "default-int" wird von C++ nicht unterst?tzt.
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(127) : error C2686: Statische und nicht-statische
Memberfunktionen mit denselben Parametertypen können nicht ?überladen werden
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(126): kann 'int java::util::Collections::Object(void)'
sein
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(127): oder "int java::util::Collections::Object(void)"
f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
til/Collections.h(127) : warning C4183: 'Object': Rückgabetyp fehlt;
Memberfunktion, die 'int' zurückgibt wird
Re: 4.3
See SOLR-4725. Basically I screwed up and introduced a change in behavior whereby defining multiple cores with the same name or dataDir will cause that core to refuse to load. Mark pointed out that having multiple cores, though dangerous, is sometimes reasonable. I've got a patch up that corrects this, and we're coordinating getting that in to the codebase. The change is that if you're using an old-style solr.xml file, you get warnings for either of those conditions. If you're using the auto-discover mode, you get warnings for two cores pointing to the same data dir, and if multiple cores with the same name Solr refuses to load. Should easily get that in place by tomorrow, say noon EST which I think fits comfortably under the 36 hour warning, thanks. Erick On Wed, Apr 17, 2013 at 12:36 PM, Simon Willnauer wrote: > wait, blockers? Sure we wait. Anything else I don't think we should wait > for. after the release is before the release. Mark, you are right it's 6 > days but there are more committers than robert and all he said is he will do > it in 2 weeks. I really feel this is a conflict of interests here at this > point and if any other non-committer would have raised that there is one or > two issue that could make it in we would have responded as usual that we > don't wait or do quick fixes or whatever else came up in the last releases. > It's a hell lot of work and if there is a blocker I am willing to do another > one. if not I will call a vote in an hour or so. > > There will always be things we want to have in and we should not block a > release because a specific person wants it in a release and that is not new > isn't it? > > nothing stops you for doing a 4.3.1 in 2 weeks and we should do more > frequent releases. if you have something serious, go volunteer and call a > vote that's how it turned out in the last couple of releases we did and I > think it's great. > > Erick, what is the issue? > > simon > > > On Wed, Apr 17, 2013 at 5:25 PM, Erick Erickson > wrote: >> >> Unfortunately I have one blocker issue for 4.3, where does that weigh >> in? I can fix it tomorrow, but I'd really hate to have it go out with >> this in. >> >> On Wed, Apr 17, 2013 at 11:07 AM, Jack Krupansky >> wrote: >> > +1 for stabilization only for 4.3 at this point. It seems like last time >> > there was at least one last minute feature change that broke something >> > in >> > 4.2 but didn’t get noticed for a few days (which is normal) but 4.2 was >> > already out by then. A two-week window would have prevented that >> > situation. >> > >> > I like the idea of a more formal “two week” window from “feature [shove] >> > freeze” to RC. And only stabilization is permitted in that window. New >> > features then continue on the main dot branch. >> > >> > And also maybe a loose “I/we would like to release in a month or so” >> > notification, which gives feature guys two weeks to get their feature in >> > before the two-week stabilization window kicks in. >> > >> > I would suggest that if anybody “planning” to release a 4.4 wants it a >> > month >> > after 4.3, they should notify the community as soon as 4.3 goes out. I >> > can >> > see doing a patch release on a moment’s notice – for stabilization bug >> > fixes >> > only, but dot feature releases should get a little more care since there >> > are >> > feature changes in play and production guys expect that a dot release >> > should >> > work at least as well as the previous dot release. >> > >> > -- Jack Krupansky >> > >> > From: Robert Muir >> > Sent: Wednesday, April 17, 2013 10:47 AM >> > To: dev@lucene.apache.org >> > Cc: simon.willna...@gmail.com >> > Subject: Re: 4.3 >> > >> > I see a few issues myself (that dont need to cause a big conflict): >> > 1. Simon doesn't want things to destabilize due to last minute >> > feature-shoving. this is a real problem and I totally see his point. >> > 2. Mark wants some time to do some cleanup/checks/bugfixing/whatever. I >> > doubt he wants to do shoving, instead I think these activities >> > contribute to >> > a quality release. >> > >> > So i'd recommend just keeping the release branch as is, give a few more >> > days >> > for additional bugfixes/docs/tests, but restrict the branch to that only >> > those changes to improve stability. >> > If this causes timing issues with release management, I'll help too >> > however >> > I can. >> > >> > On Wed, Apr 17, 2013 at 10:07 AM, Mark Miller >> > wrote: >> >> >> >> >> >> On Apr 17, 2013, at 10:04 AM, Simon Willnauer >> >> >> >> wrote: >> >> >> >> > honestly I don't think we should push in last minute changes by >> >> > saying >> >> > "oh I will wait 2 days" We should release early and often as we do >> >> > and fixes >> >> > will make it to the next release right next month. >> >> >> >> Review and bug fixes are not last minute changes. Pretending we should >> >> not >> >> focus on a release is ridicules. I want to release quality software, >> >> not >> >> hurried crap. >> >> >> >> > R
[JENKINS] Lucene-Solr-NightlyTests-4.x - Build # 235 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-4.x/235/ No tests ran. Build Log: [...truncated 442 lines...] [junit4:junit4] Completed on J0 in 388.19s, 7 testsFATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel at hudson.remoting.Request.call(Request.java:174) at hudson.remoting.Channel.call(Channel.java:672) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158) at sun.proxy.$Proxy38.join(Unknown Source) at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:915) at hudson.Launcher$ProcStarter.join(Launcher.java:360) at hudson.tasks.Ant.perform(Ant.java:217) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:810) at hudson.model.Build$BuildExecution.build(Build.java:199) at hudson.model.Build$BuildExecution.doRun(Build.java:160) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:592) at hudson.model.Run.execute(Run.java:1568) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel at hudson.remoting.Request.abort(Request.java:299) at hudson.remoting.Channel.terminate(Channel.java:732) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69) Caused by: java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50) Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2577) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1315) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369) at hudson.remoting.Command.readFrom(Command.java:92) at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4333) edismax query with escaped colon ignores AND and OR
[
https://issues.apache.org/jira/browse/SOLR-4333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer updated SOLR-4333:
-
Attachment: SOLR-4333.patch
Here is an improved test that shows off the problem a little better. This
happens when you are using boolean syntax with edismax. Either the default
query field or the singular field listed in "qf" need to be non-analyzed.
Given:
q=text_sw:(theos OR hasa\:colon OR theou)&qf=id
Get back:
{code:xml}
+(text_sw:theo (id:OR) (id:hasa:colon) (id:OR)
(id:theou)))
{code}
It fails a little differently if you use an analyzed field in "qf" (or as
default)...With:
q=text_sw:(theos OR hasa\:colon OR theou)&qf=text
Get back:
{code:xml}
+(text_sw:theo (text:"hasa colon")
(text:theou))
{code}
note the switch from "text_sw" to "text". In either case, removing the colon,
or not escaping it resolves the issue. But it would be best if clients could
send escaped colons like this so as to prevent users from using colons with
real field names (but allowing application code to do so).
> edismax query with escaped colon ignores AND and OR
> ---
>
> Key: SOLR-4333
> URL: https://issues.apache.org/jira/browse/SOLR-4333
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Affects Versions: 4.0
> Environment: tomcat 7.34
> java 7u11
> windows 2008R2
>Reporter: Robert J. van der Boon
> Attachments: SOLR-4333.patch, SOLR-4333.patch
>
>
> When I use the edismax query handler with qf=samenvatting and have a query of
> the form
> {noformat}
> a\:b AND cde
> {noformat}
> then the parsedquery ends up as:
> {noformat}
> (+(DisjunctionMaxQuery((samenvatting:"a b"))
> DisjunctionMaxQuery((samenvatting:and))
> DisjunctionMaxQuery((samenvatting:cde/no_coord
> {noformat}
> note that the AND operator is ignored, and a search for the word AND is
> performed.
> As far as I've seen it doesn't matter if the part before the \: is a real
> field or not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634308#comment-13634308 ] Erick Erickson commented on SOLR-4662: -- Well, if you're finding issues with the alternate core stuff, more tests are certainly in order ... I put up a patch on SOLR-4725 that takes out the failure case and logs a warning. For the legacy case it just logs warnings, but otherwise continues to act as before... The fiddling work there is just removing tests that should no longer fail let me know when you're done and what you've incorporated and I'll reconcile, although today I won't be doning anything after 5:00 EST, I have some commitments. > Finalize what we're going to do with solr.xml, auto-discovery, config sets. > --- > > Key: SOLR-4662 > URL: https://issues.apache.org/jira/browse/SOLR-4662 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Mark Miller >Priority: Blocker > Attachments: SOLR-4662.patch, SOLR-4662.patch, SOLR-4662.patch, > SOLR-4662.patch > > > Spinoff from SOLR-4615, breaking it out here so we can address the changes in > pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4725) Should we stop supporting "name" and "dataDir" in the autodiscover mode?
[ https://issues.apache.org/jira/browse/SOLR-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-4725: - Attachment: SOLR-4725.patch Preliminary patch to coordinate with SOLR-4662 changes Mark is doing > Should we stop supporting "name" and "dataDir" in the autodiscover mode? > > > Key: SOLR-4725 > URL: https://issues.apache.org/jira/browse/SOLR-4725 > Project: Solr > Issue Type: New Feature >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Blocker > Attachments: SOLR-4725.patch > > > Making this a blocker so we resolve it. Should be quick to code if we have > consensus, maybe nothing at all to do here. > I'm not too happy with the fact that the new core discovery process has two > real gotcha's. The individual core.properties file can define 'name' and > 'dataDir'. It seems too easy to either use the same name for two different > cores or use the same dataDir, just copy the core.properties file around and > fail to edit one them. In large installations this could be a bear to track > down. > Straw-man proposal is the we remove support for them both in discovery mode. > The name defaults to the directory in which core.properties is found and the > data dir is immediately below there. > Currently, there are checks to fail to load either core if either 'name' or > 'dataDir' is defined in more than one core. I think the error reporting is > weak, you probably have to look in the log file and there should be a way to > get this in the admin UI at least. > Maybe the right thing to do is just leave it as-is and emphasize that > specifying the dataDir and name is expert level and you have to get it right, > but I wanted to get wider exposure to the problem before we push 4.3 out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.3
On Apr 17, 2013, at 2:43 PM, Simon Willnauer wrote: > > the warning has been given 6 days ago. Robert warned 6 days ago he would roll a release in two weeks. His warning is not your warning that you would roll a release today. I think you are confusing Robert's warning for a warning you didn't give. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.3
On Wed, Apr 17, 2013 at 8:05 PM, Mark Miller wrote: > > On Apr 17, 2013, at 1:26 PM, Simon Willnauer > wrote: > > > here is my family hand holding. (btw. I think the analogy is bogus but > that is my personal opinion and I stated my points here) > > > > I will upload RC0 on Friday 36 hours from now. > > Thank you. When working with a community of developers, that is only fair. > > > Please backport bugfixes to the 4.3 branch. Please don't rush into > anything please don't make any crazy feature commits please don't make me > freak out. I still stand with my point here that this is a very bad idea > IMO and we should vote on what I have here: > > > > > http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC0-rev1468829/ > > -1 > for what reason? > > > > > is this enough for everybody or does anybody need special attention. > > It's enough for me. I like the idea of all of us working somewhat together > towards a release rather than one guy just saying this is how it is and > giving no warning to his plans. > > The Lucene community operates under the assumption that we discuss and > plan on the user list and that we give time for those in alternate > timezones and what not to participate. No warning actions are an > anti-pattern in a community larger than one, or one that is not run by a > dictator (malevolent or benevolent). > > I'm glad you decided to give us some warning. > the warning has been given 6 days ago. I am just answering the rough tone that I was facing when I say I created a release branch that's all. And honestly this bugs me a lot and makes me think a bit about this "community" of shouting. Whoever shouts loudest wins the game... my $0.05 simon > - mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: 4.3
On Apr 17, 2013, at 1:26 PM, Simon Willnauer wrote: > here is my family hand holding. (btw. I think the analogy is bogus but that > is my personal opinion and I stated my points here) > > I will upload RC0 on Friday 36 hours from now. Thank you. When working with a community of developers, that is only fair. > Please backport bugfixes to the 4.3 branch. Please don't rush into anything > please don't make any crazy feature commits please don't make me freak out. I > still stand with my point here that this is a very bad idea IMO and we should > vote on what I have here: > > http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC0-rev1468829/ -1 > > is this enough for everybody or does anybody need special attention. It's enough for me. I like the idea of all of us working somewhat together towards a release rather than one guy just saying this is how it is and giving no warning to his plans. The Lucene community operates under the assumption that we discuss and plan on the user list and that we give time for those in alternate timezones and what not to participate. No warning actions are an anti-pattern in a community larger than one, or one that is not run by a dictator (malevolent or benevolent). I'm glad you decided to give us some warning. - mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634241#comment-13634241 ] Mark Miller commented on SOLR-4662: --- I'll quickly put up a check point patch and perhaps we can commit that to help keep in sync. Down the line I think we want to add some more tests for the alternate core root directory option. > Finalize what we're going to do with solr.xml, auto-discovery, config sets. > --- > > Key: SOLR-4662 > URL: https://issues.apache.org/jira/browse/SOLR-4662 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Mark Miller >Priority: Blocker > Attachments: SOLR-4662.patch, SOLR-4662.patch, SOLR-4662.patch, > SOLR-4662.patch > > > Spinoff from SOLR-4615, breaking it out here so we can address the changes in > pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634233#comment-13634233 ] Mark Miller commented on SOLR-4662: --- I've got some work I'm in the middle of, and perhaps some more to come on further review. Most of it fairly little stuff, but also some critical stuff around using alternate root core dirs - that's what I'm involved with now, almost got it fixed and then I'll continue on and see what I find - I've already tackled a number of things though. > Finalize what we're going to do with solr.xml, auto-discovery, config sets. > --- > > Key: SOLR-4662 > URL: https://issues.apache.org/jira/browse/SOLR-4662 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Mark Miller >Priority: Blocker > Attachments: SOLR-4662.patch, SOLR-4662.patch, SOLR-4662.patch, > SOLR-4662.patch > > > Spinoff from SOLR-4615, breaking it out here so we can address the changes in > pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.3
On Wed, Apr 17, 2013 at 6:56 PM, Jack Krupansky wrote: > 4.3... are we there yet? How much longer?! > see jack this is exactly what I mean. The "how much longer" questions are the root of all evil here. IMO we should prevent this buy just calling a vote and if tehre is a serious bug the vote fails. everything else will be in a subsequent release. simon > > -- Jack Krupansky > > -Original Message- From: Otis Gospodnetic > Sent: Wednesday, April 17, 2013 12:43 PM > To: dev@lucene.apache.org ; Simon Willnauer > Subject: Re: 4.3 > > Think Family :) > > I told my wife and kids now, in April, that I'll be going to > conference in Berlin in early June. I'll still tell them about this N > times before I actually leave. I won't get in a taxi one morning > heading for the airport and tell her "Well, I told you I'd go back in > April". Well, I could try that, but I may not be allowed back home and > may have to stay in Berlin forever. > > Otis > > > > > On Wed, Apr 17, 2013 at 12:36 PM, Simon Willnauer > wrote: > >> wait, blockers? Sure we wait. Anything else I don't think we should wait >> for. after the release is before the release. Mark, you are right it's 6 >> days but there are more committers than robert and all he said is he will >> do >> it in 2 weeks. I really feel this is a conflict of interests here at this >> point and if any other non-committer would have raised that there is one >> or >> two issue that could make it in we would have responded as usual that we >> don't wait or do quick fixes or whatever else came up in the last >> releases. >> It's a hell lot of work and if there is a blocker I am willing to do >> another >> one. if not I will call a vote in an hour or so. >> >> There will always be things we want to have in and we should not block a >> release because a specific person wants it in a release and that is not >> new >> isn't it? >> >> nothing stops you for doing a 4.3.1 in 2 weeks and we should do more >> frequent releases. if you have something serious, go volunteer and call a >> vote that's how it turned out in the last couple of releases we did and I >> think it's great. >> >> Erick, what is the issue? >> >> simon >> >> >> On Wed, Apr 17, 2013 at 5:25 PM, Erick Erickson >> wrote: >> >>> >>> Unfortunately I have one blocker issue for 4.3, where does that weigh >>> in? I can fix it tomorrow, but I'd really hate to have it go out with >>> this in. >>> >>> On Wed, Apr 17, 2013 at 11:07 AM, Jack Krupansky >>> wrote: >>> > +1 for stabilization only for 4.3 at this point. It seems like last > >>> time >>> > there was at least one last minute feature change that broke something >>> > in >>> > 4.2 but didn’t get noticed for a few days (which is normal) but 4.2 was >>> > already out by then. A two-week window would have prevented that >>> > situation. >>> > >>> > I like the idea of a more formal “two week” window from “feature > >>> [shove] >>> > freeze” to RC. And only stabilization is permitted in that window. New >>> > features then continue on the main dot branch. >>> > >>> > And also maybe a loose “I/we would like to release in a month or so” >>> > notification, which gives feature guys two weeks to get their feature >>> > in >>> > before the two-week stabilization window kicks in. >>> > >>> > I would suggest that if anybody “planning” to release a 4.4 wants it a >>> > month >>> > after 4.3, they should notify the community as soon as 4.3 goes out. I >>> > can >>> > see doing a patch release on a moment’s notice – for stabilization bug >>> > fixes >>> > only, but dot feature releases should get a little more care since > >>> there >>> > are >>> > feature changes in play and production guys expect that a dot release >>> > should >>> > work at least as well as the previous dot release. >>> > >>> > -- Jack Krupansky >>> > >>> > From: Robert Muir >>> > Sent: Wednesday, April 17, 2013 10:47 AM >>> > To: dev@lucene.apache.org >>> > Cc: simon.willna...@gmail.com >>> > Subject: Re: 4.3 >>> > >>> > I see a few issues myself (that dont need to cause a big conflict): >>> > 1. Simon doesn't want things to destabilize due to last minute >>> > feature-shoving. this is a real problem and I totally see his point. >>> > 2. Mark wants some time to do some cleanup/checks/bugfixing/**whatever. >>> I >>> > doubt he wants to do shoving, instead I think these activities >>> > contribute to >>> > a quality release. >>> > >>> > So i'd recommend just keeping the release branch as is, give a few more >>> > days >>> > for additional bugfixes/docs/tests, but restrict the branch to that > >>> only >>> > those changes to improve stability. >>> > If this causes timing issues with release management, I'll help too >>> > however >>> > I can. >>> > >>> > On Wed, Apr 17, 2013 at 10:07 AM, Mark Miller >>> > wrote: >>> >> >>> >> >>> >> On Apr 17, 2013, at 10:04 AM, Simon Willnauer >>> >> >>> >> wrote: >>> >> >>> >> > honestly I don't think we should push in last minute changes by >>> >> > saying >>> >> > "o
Re: 4.3
here is my family hand holding. (btw. I think the analogy is bogus but that is my personal opinion and I stated my points here) I will upload RC0 on Friday 36 hours from now. Please backport bugfixes to the 4.3 branch. Please don't rush into anything please don't make any crazy feature commits please don't make me freak out. I still stand with my point here that this is a very bad idea IMO and we should vote on what I have here: http://people.apache.org/~simonw/staging_area/lucene-solr-4.3.0-RC0-rev1468829/ is this enough for everybody or does anybody need special attention. thanks, simon On Wed, Apr 17, 2013 at 6:56 PM, Jack Krupansky wrote: > 4.3... are we there yet? How much longer?! > > -- Jack Krupansky > > -Original Message- From: Otis Gospodnetic > Sent: Wednesday, April 17, 2013 12:43 PM > To: dev@lucene.apache.org ; Simon Willnauer > Subject: Re: 4.3 > > Think Family :) > > I told my wife and kids now, in April, that I'll be going to > conference in Berlin in early June. I'll still tell them about this N > times before I actually leave. I won't get in a taxi one morning > heading for the airport and tell her "Well, I told you I'd go back in > April". Well, I could try that, but I may not be allowed back home and > may have to stay in Berlin forever. > > Otis > > > > > On Wed, Apr 17, 2013 at 12:36 PM, Simon Willnauer > wrote: > >> wait, blockers? Sure we wait. Anything else I don't think we should wait >> for. after the release is before the release. Mark, you are right it's 6 >> days but there are more committers than robert and all he said is he will >> do >> it in 2 weeks. I really feel this is a conflict of interests here at this >> point and if any other non-committer would have raised that there is one >> or >> two issue that could make it in we would have responded as usual that we >> don't wait or do quick fixes or whatever else came up in the last >> releases. >> It's a hell lot of work and if there is a blocker I am willing to do >> another >> one. if not I will call a vote in an hour or so. >> >> There will always be things we want to have in and we should not block a >> release because a specific person wants it in a release and that is not >> new >> isn't it? >> >> nothing stops you for doing a 4.3.1 in 2 weeks and we should do more >> frequent releases. if you have something serious, go volunteer and call a >> vote that's how it turned out in the last couple of releases we did and I >> think it's great. >> >> Erick, what is the issue? >> >> simon >> >> >> On Wed, Apr 17, 2013 at 5:25 PM, Erick Erickson >> wrote: >> >>> >>> Unfortunately I have one blocker issue for 4.3, where does that weigh >>> in? I can fix it tomorrow, but I'd really hate to have it go out with >>> this in. >>> >>> On Wed, Apr 17, 2013 at 11:07 AM, Jack Krupansky >>> wrote: >>> > +1 for stabilization only for 4.3 at this point. It seems like last > >>> time >>> > there was at least one last minute feature change that broke something >>> > in >>> > 4.2 but didn’t get noticed for a few days (which is normal) but 4.2 was >>> > already out by then. A two-week window would have prevented that >>> > situation. >>> > >>> > I like the idea of a more formal “two week” window from “feature > >>> [shove] >>> > freeze” to RC. And only stabilization is permitted in that window. New >>> > features then continue on the main dot branch. >>> > >>> > And also maybe a loose “I/we would like to release in a month or so” >>> > notification, which gives feature guys two weeks to get their feature >>> > in >>> > before the two-week stabilization window kicks in. >>> > >>> > I would suggest that if anybody “planning” to release a 4.4 wants it a >>> > month >>> > after 4.3, they should notify the community as soon as 4.3 goes out. I >>> > can >>> > see doing a patch release on a moment’s notice – for stabilization bug >>> > fixes >>> > only, but dot feature releases should get a little more care since > >>> there >>> > are >>> > feature changes in play and production guys expect that a dot release >>> > should >>> > work at least as well as the previous dot release. >>> > >>> > -- Jack Krupansky >>> > >>> > From: Robert Muir >>> > Sent: Wednesday, April 17, 2013 10:47 AM >>> > To: dev@lucene.apache.org >>> > Cc: simon.willna...@gmail.com >>> > Subject: Re: 4.3 >>> > >>> > I see a few issues myself (that dont need to cause a big conflict): >>> > 1. Simon doesn't want things to destabilize due to last minute >>> > feature-shoving. this is a real problem and I totally see his point. >>> > 2. Mark wants some time to do some cleanup/checks/bugfixing/**whatever. >>> I >>> > doubt he wants to do shoving, instead I think these activities >>> > contribute to >>> > a quality release. >>> > >>> > So i'd recommend just keeping the release branch as is, give a few more >>> > days >>> > for additional bugfixes/docs/tests, but restrict the branch to that > >>> only >>> > those changes to improve stability. >>> > If this causes timi
[JENKINS] Lucene-Solr-trunk-MacOSX ([[ Exception while replacing ENV. Please report this as a bug. ]]
{{ java.lang.NullPointerException }})
- Build # 403 - Failure!
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="=_Part_24_870060212.1366219295617"
X-Jenkins-Job: Lucene-Solr-trunk-MacOSX
X-Jenkins-Result: FAILURE
Precedence: bulk
--=_Part_24_870060212.1366219295617
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/403/
Java: [[ Exception while replacing ENV. Please report this as a bug. ]]
{{ java.lang.NullPointerException }}
No tests ran.
Build Log:
[...truncated 3462 lines...]
-clover.setup:FATAL: hudson.remoting.RequestAbortedException:
java.io.IOException: Unexpected termination of the channel
-clover.setup:
clover:
common.compile-core:
compile-core:
common.compile-test:
[mkdir] Created dir:
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/grouping/classes/test
[javac] Compiling 7 source files to
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/grouping/classes/test
[echo] Building highlighter...
hudson.remoting.RequestAbortedException:
hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected
termination of the channel
at hudson.remoting.Request.call(Request.java:174)
at hudson.remoting.Channel.call(Channel.java:672)
at
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158)
at com.sun.proxy.$Proxy75.join(Unknown Source)
at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:915)
at hudson.Launcher$ProcStarter.join(Launcher.java:360)
at hudson.tasks.Ant.perform(Ant.java:217)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:802)
at hudson.model.Build$BuildExecution.build(Build.java:199)
at hudson.model.Build$BuildExecution.doRun(Build.java:160)
at
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:584)
at hudson.model.Run.execute(Run.java:1575)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:237)
Caused by: hudson.remoting.RequestAbortedException: java.io.IOException:
Unexpected termination of the channel
at hudson.remoting.Request.abort(Request.java:299)
at hudson.remoting.Channel.terminate(Channel.java:732)
at
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69)
Caused by: java.io.IOException: Unexpected termination of the channel
at
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50)
Caused by: java.io.EOFException
at
java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2577)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1315)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369)
at hudson.remoting.Command.readFrom(Command.java:92)
at
hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59)
at
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)
--=_Part_24_870060212.1366219295617--
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634219#comment-13634219 ] Erick Erickson commented on SOLR-4662: -- Hmmm, I just pulled it out, thinking of putting this in 4725. On reflection, I also think it's a good idea to pull out the checking of same that I put in for old-style solr.xml, just log both conditions rather than change existing behavior. I'm about to put a patch up for SOLR-4725 (trunk), Do you want to just incorporate that or should I just drop it and let you handle it? > Finalize what we're going to do with solr.xml, auto-discovery, config sets. > --- > > Key: SOLR-4662 > URL: https://issues.apache.org/jira/browse/SOLR-4662 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Mark Miller >Priority: Blocker > Attachments: SOLR-4662.patch, SOLR-4662.patch, SOLR-4662.patch, > SOLR-4662.patch > > > Spinoff from SOLR-4615, breaking it out here so we can address the changes in > pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3838) Multiple filter queries are not supported in the Solr Admin Query UI
[ https://issues.apache.org/jira/browse/SOLR-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3838: Attachment: SOLR-3838.patch bq. I am not a UI designer, but it might be nicer to have both "+" and "-" on each row. The "-" would let me delete the last row, and the "+" on the non-last rows would insert a blank row after the current row. If there is only one row left, "-" would simply clear its text but leave it. Me neither Jack *g [-] and [+] Buttons appear now for every row, handling as you've described it. bq. Is there any way for me to capture a query after I have gone though all this trouble to create it? I mean, why not store the parameters in the display URL so I can copy and paste it? The right side of the screen (specifically the bar on top, over the result) provides you with a link .. at least a link to the final result. of course this does not bring up the query interface with all the values you may have had, but this opens another whole *g so, would you mind we handle this in another issue? > Multiple filter queries are not supported in the Solr Admin Query UI > > > Key: SOLR-3838 > URL: https://issues.apache.org/jira/browse/SOLR-3838 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 4.0-BETA >Reporter: Jack Krupansky > Attachments: screenshot-1.jpg, SOLR-3838.patch, SOLR-3838.patch, > SOLR-3838.patch > > > The Solr Admin Query UI has only a single "fq" input field, which does not > permit the user to enter multiple filter query parameters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.3
4.3... are we there yet? How much longer?! -- Jack Krupansky -Original Message- From: Otis Gospodnetic Sent: Wednesday, April 17, 2013 12:43 PM To: dev@lucene.apache.org ; Simon Willnauer Subject: Re: 4.3 Think Family :) I told my wife and kids now, in April, that I'll be going to conference in Berlin in early June. I'll still tell them about this N times before I actually leave. I won't get in a taxi one morning heading for the airport and tell her "Well, I told you I'd go back in April". Well, I could try that, but I may not be allowed back home and may have to stay in Berlin forever. Otis On Wed, Apr 17, 2013 at 12:36 PM, Simon Willnauer wrote: wait, blockers? Sure we wait. Anything else I don't think we should wait for. after the release is before the release. Mark, you are right it's 6 days but there are more committers than robert and all he said is he will do it in 2 weeks. I really feel this is a conflict of interests here at this point and if any other non-committer would have raised that there is one or two issue that could make it in we would have responded as usual that we don't wait or do quick fixes or whatever else came up in the last releases. It's a hell lot of work and if there is a blocker I am willing to do another one. if not I will call a vote in an hour or so. There will always be things we want to have in and we should not block a release because a specific person wants it in a release and that is not new isn't it? nothing stops you for doing a 4.3.1 in 2 weeks and we should do more frequent releases. if you have something serious, go volunteer and call a vote that's how it turned out in the last couple of releases we did and I think it's great. Erick, what is the issue? simon On Wed, Apr 17, 2013 at 5:25 PM, Erick Erickson wrote: Unfortunately I have one blocker issue for 4.3, where does that weigh in? I can fix it tomorrow, but I'd really hate to have it go out with this in. On Wed, Apr 17, 2013 at 11:07 AM, Jack Krupansky wrote: > +1 for stabilization only for 4.3 at this point. It seems like last > time > there was at least one last minute feature change that broke something > in > 4.2 but didn’t get noticed for a few days (which is normal) but 4.2 was > already out by then. A two-week window would have prevented that > situation. > > I like the idea of a more formal “two week” window from “feature > [shove] > freeze” to RC. And only stabilization is permitted in that window. New > features then continue on the main dot branch. > > And also maybe a loose “I/we would like to release in a month or so” > notification, which gives feature guys two weeks to get their feature > in > before the two-week stabilization window kicks in. > > I would suggest that if anybody “planning” to release a 4.4 wants it a > month > after 4.3, they should notify the community as soon as 4.3 goes out. I > can > see doing a patch release on a moment’s notice – for stabilization bug > fixes > only, but dot feature releases should get a little more care since > there > are > feature changes in play and production guys expect that a dot release > should > work at least as well as the previous dot release. > > -- Jack Krupansky > > From: Robert Muir > Sent: Wednesday, April 17, 2013 10:47 AM > To: dev@lucene.apache.org > Cc: simon.willna...@gmail.com > Subject: Re: 4.3 > > I see a few issues myself (that dont need to cause a big conflict): > 1. Simon doesn't want things to destabilize due to last minute > feature-shoving. this is a real problem and I totally see his point. > 2. Mark wants some time to do some cleanup/checks/bugfixing/whatever. I > doubt he wants to do shoving, instead I think these activities > contribute to > a quality release. > > So i'd recommend just keeping the release branch as is, give a few more > days > for additional bugfixes/docs/tests, but restrict the branch to that > only > those changes to improve stability. > If this causes timing issues with release management, I'll help too > however > I can. > > On Wed, Apr 17, 2013 at 10:07 AM, Mark Miller > wrote: >> >> >> On Apr 17, 2013, at 10:04 AM, Simon Willnauer >> >> wrote: >> >> > honestly I don't think we should push in last minute changes by >> > saying >> > "oh I will wait 2 days" We should release early and often as we do >> > and fixes >> > will make it to the next release right next month. >> >> Review and bug fixes are not last minute changes. Pretending we should >> not >> focus on a release is ridicules. I want to release quality software, >> not >> hurried crap. >> >> > Robert say I will do one in the next 2 weeks unless somebody is >> > quicker. >> > As always folks say we release once somebody volunteers. I don't >> > know >> > how >> > often I had something in the pipeline that I wanted in the release >> > and I as >> > often we had this discussion. The 4.2 release was not even announced >> > before >> > the RC was up and I think this is how it should be. You
[jira] [Created] (SOLR-4729) Using a copyField with * as the source doesn't work
Adam Hahn created SOLR-4729: --- Summary: Using a copyField with * as the source doesn't work Key: SOLR-4729 URL: https://issues.apache.org/jira/browse/SOLR-4729 Project: Solr Issue Type: Bug Components: Schema and Analysis Affects Versions: 4.2 Reporter: Adam Hahn It seems you can no longer use a wildcard as the source when defining a copyField. I don't believe that this was fixed as part of SOLR-4650 since I've tested it with the 4/17 nightly build and it doesn't work. I'm using the following line: If I index something, this line is ignored. If I go to the Analysis tab, the fields aren't populated and I see the error: 'org.apache.solr.common.SolrException: undefined field: "*"' in the log. This worked correctly in 4.0, but I didn't test it in 4.1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.3
Think Family :) I told my wife and kids now, in April, that I'll be going to conference in Berlin in early June. I'll still tell them about this N times before I actually leave. I won't get in a taxi one morning heading for the airport and tell her "Well, I told you I'd go back in April". Well, I could try that, but I may not be allowed back home and may have to stay in Berlin forever. Otis On Wed, Apr 17, 2013 at 12:36 PM, Simon Willnauer wrote: > wait, blockers? Sure we wait. Anything else I don't think we should wait > for. after the release is before the release. Mark, you are right it's 6 > days but there are more committers than robert and all he said is he will do > it in 2 weeks. I really feel this is a conflict of interests here at this > point and if any other non-committer would have raised that there is one or > two issue that could make it in we would have responded as usual that we > don't wait or do quick fixes or whatever else came up in the last releases. > It's a hell lot of work and if there is a blocker I am willing to do another > one. if not I will call a vote in an hour or so. > > There will always be things we want to have in and we should not block a > release because a specific person wants it in a release and that is not new > isn't it? > > nothing stops you for doing a 4.3.1 in 2 weeks and we should do more > frequent releases. if you have something serious, go volunteer and call a > vote that's how it turned out in the last couple of releases we did and I > think it's great. > > Erick, what is the issue? > > simon > > > On Wed, Apr 17, 2013 at 5:25 PM, Erick Erickson > wrote: >> >> Unfortunately I have one blocker issue for 4.3, where does that weigh >> in? I can fix it tomorrow, but I'd really hate to have it go out with >> this in. >> >> On Wed, Apr 17, 2013 at 11:07 AM, Jack Krupansky >> wrote: >> > +1 for stabilization only for 4.3 at this point. It seems like last time >> > there was at least one last minute feature change that broke something >> > in >> > 4.2 but didn’t get noticed for a few days (which is normal) but 4.2 was >> > already out by then. A two-week window would have prevented that >> > situation. >> > >> > I like the idea of a more formal “two week” window from “feature [shove] >> > freeze” to RC. And only stabilization is permitted in that window. New >> > features then continue on the main dot branch. >> > >> > And also maybe a loose “I/we would like to release in a month or so” >> > notification, which gives feature guys two weeks to get their feature in >> > before the two-week stabilization window kicks in. >> > >> > I would suggest that if anybody “planning” to release a 4.4 wants it a >> > month >> > after 4.3, they should notify the community as soon as 4.3 goes out. I >> > can >> > see doing a patch release on a moment’s notice – for stabilization bug >> > fixes >> > only, but dot feature releases should get a little more care since there >> > are >> > feature changes in play and production guys expect that a dot release >> > should >> > work at least as well as the previous dot release. >> > >> > -- Jack Krupansky >> > >> > From: Robert Muir >> > Sent: Wednesday, April 17, 2013 10:47 AM >> > To: dev@lucene.apache.org >> > Cc: simon.willna...@gmail.com >> > Subject: Re: 4.3 >> > >> > I see a few issues myself (that dont need to cause a big conflict): >> > 1. Simon doesn't want things to destabilize due to last minute >> > feature-shoving. this is a real problem and I totally see his point. >> > 2. Mark wants some time to do some cleanup/checks/bugfixing/whatever. I >> > doubt he wants to do shoving, instead I think these activities >> > contribute to >> > a quality release. >> > >> > So i'd recommend just keeping the release branch as is, give a few more >> > days >> > for additional bugfixes/docs/tests, but restrict the branch to that only >> > those changes to improve stability. >> > If this causes timing issues with release management, I'll help too >> > however >> > I can. >> > >> > On Wed, Apr 17, 2013 at 10:07 AM, Mark Miller >> > wrote: >> >> >> >> >> >> On Apr 17, 2013, at 10:04 AM, Simon Willnauer >> >> >> >> wrote: >> >> >> >> > honestly I don't think we should push in last minute changes by >> >> > saying >> >> > "oh I will wait 2 days" We should release early and often as we do >> >> > and fixes >> >> > will make it to the next release right next month. >> >> >> >> Review and bug fixes are not last minute changes. Pretending we should >> >> not >> >> focus on a release is ridicules. I want to release quality software, >> >> not >> >> hurried crap. >> >> >> >> > Robert say I will do one in the next 2 weeks unless somebody is >> >> > quicker. >> >> > As always folks say we release once somebody volunteers. I don't know >> >> > how >> >> > often I had something in the pipeline that I wanted in the release >> >> > and I as >> >> > often we had this discussion. The 4.2 release was not even announced >> >> > before >> >> > the RC
Re: 4.3
wait, blockers? Sure we wait. Anything else I don't think we should wait for. after the release is before the release. Mark, you are right it's 6 days but there are more committers than robert and all he said is he will do it in 2 weeks. I really feel this is a conflict of interests here at this point and if any other non-committer would have raised that there is one or two issue that could make it in we would have responded as usual that we don't wait or do quick fixes or whatever else came up in the last releases. It's a hell lot of work and if there is a blocker I am willing to do another one. if not I will call a vote in an hour or so. There will always be things we want to have in and we should not block a release because a specific person wants it in a release and that is not new isn't it? nothing stops you for doing a 4.3.1 in 2 weeks and we should do more frequent releases. if you have something serious, go volunteer and call a vote that's how it turned out in the last couple of releases we did and I think it's great. Erick, what is the issue? simon On Wed, Apr 17, 2013 at 5:25 PM, Erick Erickson wrote: > Unfortunately I have one blocker issue for 4.3, where does that weigh > in? I can fix it tomorrow, but I'd really hate to have it go out with > this in. > > On Wed, Apr 17, 2013 at 11:07 AM, Jack Krupansky > wrote: > > +1 for stabilization only for 4.3 at this point. It seems like last time > > there was at least one last minute feature change that broke something in > > 4.2 but didn’t get noticed for a few days (which is normal) but 4.2 was > > already out by then. A two-week window would have prevented that > situation. > > > > I like the idea of a more formal “two week” window from “feature [shove] > > freeze” to RC. And only stabilization is permitted in that window. New > > features then continue on the main dot branch. > > > > And also maybe a loose “I/we would like to release in a month or so” > > notification, which gives feature guys two weeks to get their feature in > > before the two-week stabilization window kicks in. > > > > I would suggest that if anybody “planning” to release a 4.4 wants it a > month > > after 4.3, they should notify the community as soon as 4.3 goes out. I > can > > see doing a patch release on a moment’s notice – for stabilization bug > fixes > > only, but dot feature releases should get a little more care since there > are > > feature changes in play and production guys expect that a dot release > should > > work at least as well as the previous dot release. > > > > -- Jack Krupansky > > > > From: Robert Muir > > Sent: Wednesday, April 17, 2013 10:47 AM > > To: dev@lucene.apache.org > > Cc: simon.willna...@gmail.com > > Subject: Re: 4.3 > > > > I see a few issues myself (that dont need to cause a big conflict): > > 1. Simon doesn't want things to destabilize due to last minute > > feature-shoving. this is a real problem and I totally see his point. > > 2. Mark wants some time to do some cleanup/checks/bugfixing/whatever. I > > doubt he wants to do shoving, instead I think these activities > contribute to > > a quality release. > > > > So i'd recommend just keeping the release branch as is, give a few more > days > > for additional bugfixes/docs/tests, but restrict the branch to that only > > those changes to improve stability. > > If this causes timing issues with release management, I'll help too > however > > I can. > > > > On Wed, Apr 17, 2013 at 10:07 AM, Mark Miller > wrote: > >> > >> > >> On Apr 17, 2013, at 10:04 AM, Simon Willnauer < > simon.willna...@gmail.com> > >> wrote: > >> > >> > honestly I don't think we should push in last minute changes by saying > >> > "oh I will wait 2 days" We should release early and often as we do > and fixes > >> > will make it to the next release right next month. > >> > >> Review and bug fixes are not last minute changes. Pretending we should > not > >> focus on a release is ridicules. I want to release quality software, not > >> hurried crap. > >> > >> > Robert say I will do one in the next 2 weeks unless somebody is > quicker. > >> > As always folks say we release once somebody volunteers. I don't know > how > >> > often I had something in the pipeline that I wanted in the release > and I as > >> > often we had this discussion. The 4.2 release was not even announced > before > >> > the RC was up and I think this is how it should be. You can do another > >> > release soon in about 3 week or whatever. > >> > >> Dude, asking for a small amount of planning on a release seems very > >> reasonable. Wake up today and surprise "release" is ridiculous. Not > even a > >> day or two notice? > >> > >> If this is how it goes, I'm happy to just randomly start tossing up RC > all > >> the time with no discussion or notice to the list. > >> > >> I'll probably toss one up a few days after you do after I do my review. > >> > >> - Mark > >> > >> > > >> > simon > >> > > >> > > >> > On Wed, Apr 17, 2013 at 3:56 PM, Mark Miller > >
[jira] [Commented] (SOLR-3251) dynamically add fields to schema
[
https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634181#comment-13634181
]
Steve Rowe commented on SOLR-3251:
--
{quote}
{code:java}
Index: solr/core/src/java/org/apache/solr/schema/SchemaField.java
/** Declared field property overrides */
- Map args = Collections.emptyMap();
+ Map args = Collections.emptyMap();
- static SchemaField create(String name, FieldType ft, Map
props) {
+ static SchemaField create(String name, FieldType ft, Map props) {
{code}
Why are we losing type safety here? I'm now unclear on what can be in this
properties map...
{quote}
This change was in Yonik's original patch on this issue and I kept it in. If
you look at his patch, he uses this to carry Booleans in the props map:
{code:java}
Index: core/src/java/org/apache/solr/schema/FieldProperties.java
===
--- core/src/java/org/apache/solr/schema/FieldProperties.java (revision
1300409)
+++ core/src/java/org/apache/solr/schema/FieldProperties.java (working copy)
@@ -101,12 +101,13 @@
return (bitfield & props) == 0;
}
- static int parseProperties(Map properties, boolean which) {
+ static int parseProperties(Map properties, boolean which) {
int props = 0;
-for (Map.Entry entry : properties.entrySet()) {
- String val = entry.getValue();
+for (Map.Entry entry : properties.entrySet()) {
+ Object val = entry.getValue();
if(val == null) continue;
- if (Boolean.parseBoolean(val) == which) {
+ boolean boolVal = val instanceof Boolean ? (Boolean)val :
Boolean.parseBoolean(val.toString());
+ if (boolVal == which) {
props |= propertyNameToInt(entry.getKey());
}
}
{code}
> dynamically add fields to schema
>
>
> Key: SOLR-3251
> URL: https://issues.apache.org/jira/browse/SOLR-3251
> Project: Solr
> Issue Type: New Feature
>Reporter: Yonik Seeley
>Assignee: Steve Rowe
> Fix For: 4.3, 5.0
>
> Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch,
> SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch
>
>
> One related piece of functionality needed for SOLR-3250 is the ability to
> dynamically add a field to the schema.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_17) - Build # 5212 - Failure!
I see the bug (two bugs).
One bug is the test does IndexSearcher.search(query, Integer.MAX_VALUE,
sort)
In the case of search-without-sort, there is some code that essentially
does Math.min(maxdoc, ndoc) so that if you request more documents than
actually exist in the index, we create a smaller priority queue. I think
Uwe added that not so long ago. But this code isn't in search-with-sort...
Index: lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
===
--- lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
(revision 1468947)
+++ lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
(working copy)
@@ -511,6 +511,12 @@
if (sort == null) throw new NullPointerException("Sort must not be
null");
+int limit = reader.maxDoc();
+if (limit == 0) {
+ limit = 1;
+}
+nDocs = Math.min(nDocs, limit);
+
if (executor == null) {
// use all leaves here!
return search(leafContexts, weight, after, nDocs, sort, fillFields,
doDocScores, doMaxScore);
Index:
lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
===
---
lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
(revision 1468947)
+++
lucene/queries/src/test/org/apache/lucene/queries/function/TestFunctionQuerySort.java
(working copy)
@@ -69,7 +69,7 @@
// Get hits sorted by our FunctionValues (ascending values)
Query q = new MatchAllDocsQuery();
-TopDocs hits = searcher.search(q, Integer.MAX_VALUE, orderBy);
+TopDocs hits = searcher.search(q, reader.maxDoc(), orderBy);
assertEquals(NUM_VALS, hits.scoreDocs.length);
// Verify that sorting works in general
int i = 0;
@@ -81,7 +81,7 @@
// Now get hits after hit #2 using IS.searchAfter()
int afterIdx = 1;
FieldDoc afterHit = (FieldDoc) hits.scoreDocs[afterIdx];
-hits = searcher.searchAfter(afterHit, q, Integer.MAX_VALUE, orderBy);
+hits = searcher.searchAfter(afterHit, q, reader.maxDoc(), orderBy);
// Expected # of hits: NUM_VALS - 2
assertEquals(NUM_VALS - (afterIdx + 1), hits.scoreDocs.length);
On Wed, Apr 17, 2013 at 10:54 AM, Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/5212/
> Java: 32bit/jdk1.7.0_17 -client -XX:+UseG1GC
>
> 1 tests failed.
> REGRESSION:
>
> org.apache.lucene.queries.function.TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues
>
> Error Message:
> Requested array size exceeds VM limit
>
> Stack Trace:
> java.lang.OutOfMemoryError: Requested array size exceeds VM limit
> at
> __randomizedtesting.SeedInfo.seed([19CBB97056276D92:E7ABF8B5EEE0EA22]:0)
> at
> org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:64)
> at
> org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:37)
> at
> org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:138)
> at
> org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:34)
> at
> org.apache.lucene.search.FieldValueHitQueue$OneComparatorFieldValueHitQueue.(FieldValueHitQueue.java:63)
> at
> org.apache.lucene.search.FieldValueHitQueue.create(FieldValueHitQueue.java:171)
> at
> org.apache.lucene.search.TopFieldCollector.create(TopFieldCollector.java:1123)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:518)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:493)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:370)
> at
> org.apache.lucene.queries.function.TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues(TestFunctionQuerySort.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at
> org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
> at
> org.apache.lucene.util.Abstract
[jira] [Commented] (SOLR-3251) dynamically add fields to schema
[
https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634179#comment-13634179
]
Steve Rowe commented on SOLR-3251:
--
{quote}
And by the way, i'm sorry if this suggestion seems to conflict with my previous
one. My problem before was SolrIndexSearcher publicly exposing a
moving-target-schema, which I still insist is bad. So its good the patch fixes
that, but I'm not sure if removing the getter is the only solution.
My question is: why does it need a moving target at all (even internally). If
it can have an immutable snapshot, then its getter is ok and search code works
as before. We could keep it (and maybe deprecate if we dont want to have 87
different ways to get the schema, doesnt matter so much at that point).
{quote}
No problem, I understand. I'll recast as bind-schema-to-searcher and see how
that goes.
> dynamically add fields to schema
>
>
> Key: SOLR-3251
> URL: https://issues.apache.org/jira/browse/SOLR-3251
> Project: Solr
> Issue Type: New Feature
>Reporter: Yonik Seeley
>Assignee: Steve Rowe
> Fix For: 4.3, 5.0
>
> Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch,
> SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch
>
>
> One related piece of functionality needed for SOLR-3250 is the ability to
> dynamically add a field to the schema.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3251) dynamically add fields to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634161#comment-13634161 ] Robert Muir commented on SOLR-3251: --- And by the way, i'm sorry if this suggestion seems to conflict with my previous one. My problem before was SolrIndexSearcher publicly exposing a moving-target-schema, which I still insist is bad. So its good the patch fixes that, but I'm not sure if removing the getter is the only solution. My question is: why does it need a moving target at all (even internally). If it can have an immutable snapshot, then its getter is ok and search code works as before. We could keep it (and maybe deprecate if we dont want to have 87 different ways to get the schema, doesnt matter so much at that point). > dynamically add fields to schema > > > Key: SOLR-3251 > URL: https://issues.apache.org/jira/browse/SOLR-3251 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley >Assignee: Steve Rowe > Fix For: 4.3, 5.0 > > Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch, > SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch > > > One related piece of functionality needed for SOLR-3250 is the ability to > dynamically add a field to the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3251) dynamically add fields to schema
[
https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634150#comment-13634150
]
Robert Muir commented on SOLR-3251:
---
+++ solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java
(working copy)
@@ -120,7 +120,6 @@
{code}
private static Logger log = LoggerFactory.getLogger(SolrIndexSearcher.class);
private final SolrCore core;
- private final IndexSchema schema;
{code}
Are we sure SolrIndexSearcher cannot just take a snapshot of the schema and
just use that? After all, it represents an immutable point-in-time of the index.
Requests already have indexsearchers assigned to them, so req.getSchema() could
just forward to getSearcher().getSchema(). Then the patch would get a lot
smaller and so much search code would be simpler and probably require no code
or API changes at all to work.
The special cases like real-time get could continue to just call
getLatestSchema() from the core.
This seems to cause a lot of general problems throughout the patch (and require
lots of search code to become more complex, taking additional IndexSchema
parameters). After making it halfway thru the patch, I think doing a small
change here might fix 90% of my other comments (but im including them anyway
here, sorry if thats confusing, just want
to reduce the number of iterations hopefully)
solr/core/src/java/org/apache/solr/handler/component/FieldFacetStats.java
{code}
+facetStats.accumulate(searcher.getCore().getLatestSchema(), value,
count);
{code}
Shouldn't this be using the one from the request instead of the moving target?
Index:
solr/core/src/java/org/apache/solr/handler/component/QueryElevationComponent.java?
{code}
@Override
public void inform(SolrCore core) {
-String a = initArgs.get(FIELD_TYPE);
-if (a != null) {
- FieldType ft = core.getSchema().getFieldTypes().get(a);
+IndexSchema schema = core.getLatestSchema();
{code}
Index:
solr/core/src/java/org/apache/solr/handler/component/SpellCheckComponent.java
{code}
+IndexSchema schema = core.getLatestSchema();
{code}
These look scary, but seem ok since it only uses the fieldtype (which cannot
yet change).
Maybe add a comment just so its clear (especially in case the fieldtype becomes
changeable later)?
+++ solr/core/src/java/org/apache/solr/handler/component/StatsComponent.java
(working copy)
{code}
boolean isShard = params.getBool(ShardParams.IS_SHARD, false);
if (null != statsFs) {
+ IndexSchema schema = searcher.getCore().getLatestSchema();
public NamedList getFieldCacheStats(String fieldName, String[] facet)
throws IOException {
-final SchemaField sf = searcher.getSchema().getField(fieldName);
+IndexSchema schema = searcher.getCore().getLatestSchema();
+final SchemaField sf = schema.getField(fieldName);
{code}
This should be using the one from the request instead of the moving target.
Index: solr/core/src/java/org/apache/solr/handler/loader/CSVLoaderBase.java
{code}
-schema = req.getSchema();
+core = req.getCore();
this.literals = new HashMap();
templateAdd = new AddUpdateCommand(req);
@@ -244,6 +245,7 @@
CSVLoaderBase.FieldAdder adder = new CSVLoaderBase.FieldAdder();
CSVLoaderBase.FieldAdder adderKeepEmpty = new
CSVLoaderBase.FieldAdderEmpty();
+IndexSchema schema = core.getLatestSchema();
{code}
Is this right? Why not use the one from the request? If there is a reason
(which i dont see/understand), can we add a comment?
Index: solr/core/src/java/org/apache/solr/schema/SchemaField.java
{code}
/** Declared field property overrides */
- Map args = Collections.emptyMap();
+ Map args = Collections.emptyMap();
- static SchemaField create(String name, FieldType ft, Map
props) {
+ static SchemaField create(String name, FieldType ft, Map props) {
{code}
Why are we losing type safety here? I'm now unclear on what can be in this
properties map...
Index: solr/core/src/java/org/apache/solr/search/Grouping.java
{code}
@@ -775,6 +776,7 @@
// handle case of rows=0
if (numGroups == 0) return;
+ IndexSchema schema = searcher.getCore().getLatestSchema();
{code}
I don't think this should be using a moving target
+++ solr/core/src/java/org/apache/solr/search/JoinQParserPlugin.java
(working copy)
{code}
- String prefixStr =
TrieField.getMainValuePrefix(fromSearcher.getSchema().getFieldType(fromField));
+ String prefixStr =
TrieField.getMainValuePrefix(fromSearcher.getCore().getLatestSchema().getFieldType(fromField));
{code}
Nor this
> dynamically add fields to schema
>
>
> Key: SOLR-3251
> URL: https://issues.apache.org/jira/browse/SOLR-3251
> Project: Solr
> Issue Type: New Feature
>Reporter: Yonik Seeley
>Assignee: Steve Row
[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634138#comment-13634138 ] Mark Miller commented on SOLR-4662: --- I've got it, I'm working on a pass that has a few updates and fixes. bq. How about a warning in the log file though? That seems fine to me. bq. I take it there's no similar argument for core names? Having two cores with the same name seems...fraught. Right, that should fail. > Finalize what we're going to do with solr.xml, auto-discovery, config sets. > --- > > Key: SOLR-4662 > URL: https://issues.apache.org/jira/browse/SOLR-4662 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Mark Miller >Priority: Blocker > Attachments: SOLR-4662.patch, SOLR-4662.patch, SOLR-4662.patch, > SOLR-4662.patch > > > Spinoff from SOLR-4615, breaking it out here so we can address the changes in > pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634134#comment-13634134 ] Erick Erickson commented on SOLR-4662: -- Hmmm, OK, I can pull that out ASAP. How about a warning in the log file though? I think it's important to provide some way to debug this when it happens by accident rather than manual inspection of potentially a bazillion files. I take it there's no similar argument for core names? Having two cores with the same name seems...fraught. > Finalize what we're going to do with solr.xml, auto-discovery, config sets. > --- > > Key: SOLR-4662 > URL: https://issues.apache.org/jira/browse/SOLR-4662 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Mark Miller >Priority: Blocker > Attachments: SOLR-4662.patch, SOLR-4662.patch, SOLR-4662.patch, > SOLR-4662.patch > > > Spinoff from SOLR-4615, breaking it out here so we can address the changes in > pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reopened SOLR-4662: --- Assignee: Mark Miller (was: Erick Erickson) Reopening - I'm going to take a close pass over this. > Finalize what we're going to do with solr.xml, auto-discovery, config sets. > --- > > Key: SOLR-4662 > URL: https://issues.apache.org/jira/browse/SOLR-4662 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Mark Miller >Priority: Blocker > Attachments: SOLR-4662.patch, SOLR-4662.patch, SOLR-4662.patch, > SOLR-4662.patch > > > Spinoff from SOLR-4615, breaking it out here so we can address the changes in > pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.3
Unfortunately I have one blocker issue for 4.3, where does that weigh in? I can fix it tomorrow, but I'd really hate to have it go out with this in. On Wed, Apr 17, 2013 at 11:07 AM, Jack Krupansky wrote: > +1 for stabilization only for 4.3 at this point. It seems like last time > there was at least one last minute feature change that broke something in > 4.2 but didn’t get noticed for a few days (which is normal) but 4.2 was > already out by then. A two-week window would have prevented that situation. > > I like the idea of a more formal “two week” window from “feature [shove] > freeze” to RC. And only stabilization is permitted in that window. New > features then continue on the main dot branch. > > And also maybe a loose “I/we would like to release in a month or so” > notification, which gives feature guys two weeks to get their feature in > before the two-week stabilization window kicks in. > > I would suggest that if anybody “planning” to release a 4.4 wants it a month > after 4.3, they should notify the community as soon as 4.3 goes out. I can > see doing a patch release on a moment’s notice – for stabilization bug fixes > only, but dot feature releases should get a little more care since there are > feature changes in play and production guys expect that a dot release should > work at least as well as the previous dot release. > > -- Jack Krupansky > > From: Robert Muir > Sent: Wednesday, April 17, 2013 10:47 AM > To: dev@lucene.apache.org > Cc: simon.willna...@gmail.com > Subject: Re: 4.3 > > I see a few issues myself (that dont need to cause a big conflict): > 1. Simon doesn't want things to destabilize due to last minute > feature-shoving. this is a real problem and I totally see his point. > 2. Mark wants some time to do some cleanup/checks/bugfixing/whatever. I > doubt he wants to do shoving, instead I think these activities contribute to > a quality release. > > So i'd recommend just keeping the release branch as is, give a few more days > for additional bugfixes/docs/tests, but restrict the branch to that only > those changes to improve stability. > If this causes timing issues with release management, I'll help too however > I can. > > On Wed, Apr 17, 2013 at 10:07 AM, Mark Miller wrote: >> >> >> On Apr 17, 2013, at 10:04 AM, Simon Willnauer >> wrote: >> >> > honestly I don't think we should push in last minute changes by saying >> > "oh I will wait 2 days" We should release early and often as we do and >> > fixes >> > will make it to the next release right next month. >> >> Review and bug fixes are not last minute changes. Pretending we should not >> focus on a release is ridicules. I want to release quality software, not >> hurried crap. >> >> > Robert say I will do one in the next 2 weeks unless somebody is quicker. >> > As always folks say we release once somebody volunteers. I don't know how >> > often I had something in the pipeline that I wanted in the release and I as >> > often we had this discussion. The 4.2 release was not even announced before >> > the RC was up and I think this is how it should be. You can do another >> > release soon in about 3 week or whatever. >> >> Dude, asking for a small amount of planning on a release seems very >> reasonable. Wake up today and surprise "release" is ridiculous. Not even a >> day or two notice? >> >> If this is how it goes, I'm happy to just randomly start tossing up RC all >> the time with no discussion or notice to the list. >> >> I'll probably toss one up a few days after you do after I do my review. >> >> - Mark >> >> > >> > simon >> > >> > >> > On Wed, Apr 17, 2013 at 3:56 PM, Mark Miller >> > wrote: >> > How about a short heads up so that people working on 4.3 issues can >> > actually wrap up? I know I have review I want to finish before 4.3 at >> > least. >> > >> > Robert gave a warning of 2 weeks, then less than a week later you say, >> > I'm rolling now? Can't we at least have a day or two notice to wrap? >> > >> > - Mark >> > >> > On Apr 17, 2013, at 5:16 AM, Simon Willnauer >> > wrote: >> > >> > > Folks, >> > > >> > > I started a release branch for Lucene / Solr 4.3 >> > > https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/ >> > > I will update the 4.x branch now and build the first RC >> > > >> > > simon >> > > >> > > >> > > On Thu, Apr 11, 2013 at 1:21 AM, Robert Muir wrote: >> > > 4.3 is looking good already. If nobody has spun a release candidate in >> > > two weeks, I will. >> > > >> > > >> > >> > >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634113#comment-13634113 ] Mark Miller commented on SOLR-4662: --- Finally getting to doing some review here. I'm -1 on the prevention of different cores having the same data directory. The lock factory is there to help there, and if you want to configure many cores to do read only against a datadir, you should be able to. > Finalize what we're going to do with solr.xml, auto-discovery, config sets. > --- > > Key: SOLR-4662 > URL: https://issues.apache.org/jira/browse/SOLR-4662 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Blocker > Attachments: SOLR-4662.patch, SOLR-4662.patch, SOLR-4662.patch, > SOLR-4662.patch > > > Spinoff from SOLR-4615, breaking it out here so we can address the changes in > pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.3
+1 for stabilization only for 4.3 at this point. It seems like last time there was at least one last minute feature change that broke something in 4.2 but didn’t get noticed for a few days (which is normal) but 4.2 was already out by then. A two-week window would have prevented that situation. I like the idea of a more formal “two week” window from “feature [shove] freeze” to RC. And only stabilization is permitted in that window. New features then continue on the main dot branch. And also maybe a loose “I/we would like to release in a month or so” notification, which gives feature guys two weeks to get their feature in before the two-week stabilization window kicks in. I would suggest that if anybody “planning” to release a 4.4 wants it a month after 4.3, they should notify the community as soon as 4.3 goes out. I can see doing a patch release on a moment’s notice – for stabilization bug fixes only, but dot feature releases should get a little more care since there are feature changes in play and production guys expect that a dot release should work at least as well as the previous dot release. -- Jack Krupansky From: Robert Muir Sent: Wednesday, April 17, 2013 10:47 AM To: dev@lucene.apache.org Cc: simon.willna...@gmail.com Subject: Re: 4.3 I see a few issues myself (that dont need to cause a big conflict): 1. Simon doesn't want things to destabilize due to last minute feature-shoving. this is a real problem and I totally see his point. 2. Mark wants some time to do some cleanup/checks/bugfixing/whatever. I doubt he wants to do shoving, instead I think these activities contribute to a quality release. So i'd recommend just keeping the release branch as is, give a few more days for additional bugfixes/docs/tests, but restrict the branch to that only those changes to improve stability. If this causes timing issues with release management, I'll help too however I can. On Wed, Apr 17, 2013 at 10:07 AM, Mark Miller wrote: On Apr 17, 2013, at 10:04 AM, Simon Willnauer wrote: > honestly I don't think we should push in last minute changes by saying "oh I will wait 2 days" We should release early and often as we do and fixes will make it to the next release right next month. Review and bug fixes are not last minute changes. Pretending we should not focus on a release is ridicules. I want to release quality software, not hurried crap. > Robert say I will do one in the next 2 weeks unless somebody is quicker. As always folks say we release once somebody volunteers. I don't know how often I had something in the pipeline that I wanted in the release and I as often we had this discussion. The 4.2 release was not even announced before the RC was up and I think this is how it should be. You can do another release soon in about 3 week or whatever. Dude, asking for a small amount of planning on a release seems very reasonable. Wake up today and surprise "release" is ridiculous. Not even a day or two notice? If this is how it goes, I'm happy to just randomly start tossing up RC all the time with no discussion or notice to the list. I'll probably toss one up a few days after you do after I do my review. - Mark > > simon > > > On Wed, Apr 17, 2013 at 3:56 PM, Mark Miller wrote: > How about a short heads up so that people working on 4.3 issues can actually wrap up? I know I have review I want to finish before 4.3 at least. > > Robert gave a warning of 2 weeks, then less than a week later you say, I'm rolling now? Can't we at least have a day or two notice to wrap? > > - Mark > > On Apr 17, 2013, at 5:16 AM, Simon Willnauer wrote: > > > Folks, > > > > I started a release branch for Lucene / Solr 4.3 https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/ > > I will update the 4.x branch now and build the first RC > > > > simon > > > > > > On Thu, Apr 11, 2013 at 1:21 AM, Robert Muir wrote: > > 4.3 is looking good already. If nobody has spun a release candidate in two weeks, I will. > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4935) CustomScoreQuery has broken boosting
[ https://issues.apache.org/jira/browse/LUCENE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-4935. - Resolution: Fixed Fix Version/s: 4.4 5.0 > CustomScoreQuery has broken boosting > > > Key: LUCENE-4935 > URL: https://issues.apache.org/jira/browse/LUCENE-4935 > Project: Lucene - Core > Issue Type: Bug > Components: core/query/scoring >Reporter: Robert Muir > Fix For: 5.0, 4.4 > > Attachments: LUCENE-4935.patch, LUCENE-4935.patch > > > CustomScoreQuery wrongly applies boost^2 instead of boost. > It wrongly incorporates its boost into the normalization factor passed down > to subquery (like booleanquery does) and *also* multiplies it directly in its > scorer. > The only reason the test passes today is because it compares raw score > magnitudes when querynorm is on, which normalizes this away. > Changing the test to use newSearcher() demonstrates the brokenness. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_17) - Build # 5212 - Failure!
Whats going on here? I saw this with jrockit too. Maybe its a bug in the test On Wed, Apr 17, 2013 at 10:54 AM, Policeman Jenkins Server < jenk...@thetaphi.de> wrote: > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/5212/ > Java: 32bit/jdk1.7.0_17 -client -XX:+UseG1GC > > 1 tests failed. > REGRESSION: > > org.apache.lucene.queries.function.TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues > > Error Message: > Requested array size exceeds VM limit > > Stack Trace: > java.lang.OutOfMemoryError: Requested array size exceeds VM limit > at > __randomizedtesting.SeedInfo.seed([19CBB97056276D92:E7ABF8B5EEE0EA22]:0) > at > org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:64) > at > org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:37) > at > org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:138) > at > org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:34) > at > org.apache.lucene.search.FieldValueHitQueue$OneComparatorFieldValueHitQueue.(FieldValueHitQueue.java:63) > at > org.apache.lucene.search.FieldValueHitQueue.create(FieldValueHitQueue.java:171) > at > org.apache.lucene.search.TopFieldCollector.create(TopFieldCollector.java:1123) > at > org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:518) > at > org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:493) > at > org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:370) > at > org.apache.lucene.queries.function.TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues(TestFunctionQuerySort.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) > at > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) > at > org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) > at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) > at > com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) > at > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) > at > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) > at > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) > > > > > Build Log: > [...truncated 7591 lines...] > [junit4:junit4] Suite: > org.apache.lucene.queries.function.TestFunctionQuerySort > [junit4:junit4] 2> NOTE: reproduce with: ant test > -Dtestcase=TestFunctionQuerySort > -Dtests.method=testSearchAfterWhenSortingByFunctionValues > -Dtests.seed=19CBB97056276D92 -Dtests.multiplier=3 -Dtests.slow=true > -Dtests.locale=be -Dtests.timezone=Pacific/Tongatapu > -Dtests.file.encoding=US-ASCII > [junit4:junit4] ERROR 0.58s J0 | > TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues <<< > [junit4:junit4]> Throwable #1: java.lang.OutOfMemoryError: Requested > array size exceeds VM limit > [junit4:junit4]>at > __randomizedtesting.SeedInfo.seed([19CBB97056276D92:E7ABF8B5EEE0EA22]:0) > [junit4:junit4]>at > org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:64) > [junit4:junit4]>at > org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:37) > [junit4:junit4]>at > org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:138) > [junit4:junit4]>at > org.apache.lucene.sear
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_17) - Build # 5212 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/5212/ Java: 32bit/jdk1.7.0_17 -client -XX:+UseG1GC 1 tests failed. REGRESSION: org.apache.lucene.queries.function.TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues Error Message: Requested array size exceeds VM limit Stack Trace: java.lang.OutOfMemoryError: Requested array size exceeds VM limit at __randomizedtesting.SeedInfo.seed([19CBB97056276D92:E7ABF8B5EEE0EA22]:0) at org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:64) at org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:37) at org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:138) at org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:34) at org.apache.lucene.search.FieldValueHitQueue$OneComparatorFieldValueHitQueue.(FieldValueHitQueue.java:63) at org.apache.lucene.search.FieldValueHitQueue.create(FieldValueHitQueue.java:171) at org.apache.lucene.search.TopFieldCollector.create(TopFieldCollector.java:1123) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:518) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:493) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:370) at org.apache.lucene.queries.function.TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues(TestFunctionQuerySort.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) Build Log: [...truncated 7591 lines...] [junit4:junit4] Suite: org.apache.lucene.queries.function.TestFunctionQuerySort [junit4:junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestFunctionQuerySort -Dtests.method=testSearchAfterWhenSortingByFunctionValues -Dtests.seed=19CBB97056276D92 -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=be -Dtests.timezone=Pacific/Tongatapu -Dtests.file.encoding=US-ASCII [junit4:junit4] ERROR 0.58s J0 | TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues <<< [junit4:junit4]> Throwable #1: java.lang.OutOfMemoryError: Requested array size exceeds VM limit [junit4:junit4]>at __randomizedtesting.SeedInfo.seed([19CBB97056276D92:E7ABF8B5EEE0EA22]:0) [junit4:junit4]>at org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:64) [junit4:junit4]>at org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:37) [junit4:junit4]>at org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:138) [junit4:junit4]>at org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:34) [junit4:junit4]>at org.apache.lucene.search.FieldValueHitQueue$OneComparatorFieldValueHitQueue.(FieldValueHitQueue.java:63) [junit4:junit4]>at org.apache.lucene.search.FieldValueHitQueue.create(FieldValueHitQueue.java:171) [junit4:junit4]>at org.apache.luc
Re: AW: [VOTE] Release PyLucene 4.2.1
On Apr 17, 2013, at 1:29, "Thomas Koch" wrote:
> Hi Andi,
> sorry, but -1 for Windows build:
>
> OK: I was able to build JCC 1.16 with Python27 on Win32 (Win7).
> Fail: I could not build PyLucene 4.2.1 with Python27 and Java 1.6.
>
> After having upgraded from my old ant 1.8.0 to ant 1.9.0 (make now requires
> ant 1.8.2) I could also run make (the ivy-target successfully downloaded and
> installed ivy-2.3.0.jar in my C:\Users\Koch\.ant\lib dir, btw). However the
> build fails with a compiler error:
>
> error: command '"C:\Program Files\Microsoft Visual Studio
> 9.0\VC\BIN\cl.exe"' failed with exit status 2
> make: *** [compile] Error 1
>
> details attached - I don't actually see any syntax error (though my C++
> knowledge is bit outdated) and assume it's all caused by the declaration of
> max() which VC9 understands as macro (why?). Unfortunately VisualStudio
> Messages are all in German - the ones about macro translate to
>
> Collections.h(126) : warning C4003: not enough parameters provided for macro
> 'max'
> same for min:
> Collections.h(128) : warning C4003: not enough parameters provided for macro
> 'min'
>
> Note: I used the same MS-VisualStudio 9 (and same machine/setup – except of
> ant) I used to build PyLucene 3.6.x before (successfully). However the
> Collections seems to be new in 4.2
>
> The lines 126-129 in java/util/Collections.h are:
> static ::java::lang::Object max(const ::java::util::Collection &);
> static ::java::lang::Object max(const ::java::util::Collection &,
> const ::java::util::Comparator &);
> static ::java::lang::Object min(const ::java::util::Collection &);
> static ::java::lang::Object min(const ::java::util::Collection &,
> const ::java::util::Comparator &);
>
> Any ideas?
Yes, this can probably be worked around by adding min and max to the reserved
words list via --reserved or by renaming then in collections.
Andi..
>
> Regards,
> Thomas
> --
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(126) : warning C4003: Nicht genügend übergebene Parameter
> für das Makro 'max'
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(126) : error C2059: Syntaxfehler: '('
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(126) : error C2059: Syntaxfehler: ')'
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(126) : error C2143: Syntaxfehler: Es fehlt ')' vor '?'
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(126) : error C2143: Syntaxfehler: Es fehlt ';' vor '?'
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(126) : error C4430: Fehlender Typspezifizierer - int wird
> angenommen. Hinweis: "default-int" wird von C++ nicht untersttzt.
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(126) : warning C4183: 'Object': Rückgabetyp fehlt;
> Memberfunktion, die 'int' zurckgibt wird angenommen
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(126) : error C2334: Unerwartete(s) Token vor ':';
> sichtbarer Funktionstext wird übersprungen
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(126) : error C2760: Syntaxfehler: '{' erwartet und nicht
> ';'
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(127) : error C2144: Syntaxfehler: 'java::lang::Object'
> sollte auf '}' folgen
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(127) : error C2059: Syntaxfehler: '('
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(127) : error C2059: Syntaxfehler: ')'
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(127) : error C2143: Syntaxfehler: Es fehlt ')' vor '?'
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(127) : error C2143: Syntaxfehler: Es fehlt ';' vor '?'
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(127) : error C4430: Fehlender Typspezifizierer - int wird
> angenommen. Hinweis: "default-int" wird von C++ nicht untersttzt.
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(127) : error C2686: Statische und nicht-statische
> Memberfunktionen mit denselben Parametertypen können nicht überladen werden
>
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(126): kann 'int java::util::Collections::Object(void)'
> sein
>
> f:\devel\workspaces\workspace.pylucene\pylucene-4.2.1-0\build\_lucene\java/u
> til/Collections.h(127): oder "int java::u
Re: 4.3
+1 I'm investigating the ShardSplitTest failures. On Wed, Apr 17, 2013 at 8:02 PM, Yonik Seeley wrote: > On Wed, Apr 17, 2013 at 5:16 AM, Simon Willnauer > wrote: > > I started a release branch for Lucene / Solr 4.3 > > https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/ > > I will update the 4.x branch now and build the first RC > > There are quite a few people still finishing things up for 4.3 > Seems like we should wait another week and re-cut the branch after it > seems like everyone is ready. > > -Yonik > http://lucidworks.com > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Regards, Shalin Shekhar Mangar.
Re: 4.3
I see a few issues myself (that dont need to cause a big conflict): 1. Simon doesn't want things to destabilize due to last minute feature-shoving. this is a real problem and I totally see his point. 2. Mark wants some time to do some cleanup/checks/bugfixing/whatever. I doubt he wants to do shoving, instead I think these activities contribute to a quality release. So i'd recommend just keeping the release branch as is, give a few more days for additional bugfixes/docs/tests, but restrict the branch to that only those changes to improve stability. If this causes timing issues with release management, I'll help too however I can. On Wed, Apr 17, 2013 at 10:07 AM, Mark Miller wrote: > > On Apr 17, 2013, at 10:04 AM, Simon Willnauer > wrote: > > > honestly I don't think we should push in last minute changes by saying > "oh I will wait 2 days" We should release early and often as we do and > fixes will make it to the next release right next month. > > Review and bug fixes are not last minute changes. Pretending we should not > focus on a release is ridicules. I want to release quality software, not > hurried crap. > > > Robert say I will do one in the next 2 weeks unless somebody is quicker. > As always folks say we release once somebody volunteers. I don't know how > often I had something in the pipeline that I wanted in the release and I as > often we had this discussion. The 4.2 release was not even announced before > the RC was up and I think this is how it should be. You can do another > release soon in about 3 week or whatever. > > Dude, asking for a small amount of planning on a release seems very > reasonable. Wake up today and surprise "release" is ridiculous. Not even a > day or two notice? > > If this is how it goes, I'm happy to just randomly start tossing up RC all > the time with no discussion or notice to the list. > > I'll probably toss one up a few days after you do after I do my review. > > - Mark > > > > > simon > > > > > > On Wed, Apr 17, 2013 at 3:56 PM, Mark Miller > wrote: > > How about a short heads up so that people working on 4.3 issues can > actually wrap up? I know I have review I want to finish before 4.3 at > least. > > > > Robert gave a warning of 2 weeks, then less than a week later you say, > I'm rolling now? Can't we at least have a day or two notice to wrap? > > > > - Mark > > > > On Apr 17, 2013, at 5:16 AM, Simon Willnauer > wrote: > > > > > Folks, > > > > > > I started a release branch for Lucene / Solr 4.3 > https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/ > > > I will update the 4.x branch now and build the first RC > > > > > > simon > > > > > > > > > On Thu, Apr 11, 2013 at 1:21 AM, Robert Muir wrote: > > > 4.3 is looking good already. If nobody has spun a release candidate in > two weeks, I will. > > > > > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
RE: 4.3
+1 Robert and Me are also fixing some inconsistencies with numerics and doc-values. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik > Seeley > Sent: Wednesday, April 17, 2013 4:32 PM > To: Lucene Dev; Simon Willnauer > Subject: Re: 4.3 > > On Wed, Apr 17, 2013 at 5:16 AM, Simon Willnauer > wrote: > > I started a release branch for Lucene / Solr 4.3 > > https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/ > > I will update the 4.x branch now and build the first RC > > There are quite a few people still finishing things up for 4.3 Seems like we > should wait another week and re-cut the branch after it seems like everyone > is ready. > > -Yonik > http://lucidworks.com > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.3
On Apr 17, 2013, at 10:32 AM, Yonik Seeley wrote: > On Wed, Apr 17, 2013 at 5:16 AM, Simon Willnauer > wrote: >> I started a release branch for Lucene / Solr 4.3 >> https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/ >> I will update the 4.x branch now and build the first RC > > There are quite a few people still finishing things up for 4.3 > Seems like we should wait another week and re-cut the branch after it > seems like everyone is ready. +1 (I want to get SOLR-3251 in.) Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.3
On Wed, Apr 17, 2013 at 5:16 AM, Simon Willnauer wrote: > I started a release branch for Lucene / Solr 4.3 > https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/ > I will update the 4.x branch now and build the first RC There are quite a few people still finishing things up for 4.3 Seems like we should wait another week and re-cut the branch after it seems like everyone is ready. -Yonik http://lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.3
On Apr 17, 2013, at 10:13 AM, Simon Willnauer wrote: > dude you had 12 days since rob send the note to the list. what are you > talking about? What are you talking about? It has not been 12 days. - mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.3
I thought I had two weeks, so that's what I planned on. I figured that if someone else pick up the baton first, they would actually be decent and give a day or two notice. I didn't go, oh, Rob said two weeks, but some dude might just say "I'm building an RC right now!" at any moment. It's not normally how we operate. Normally, there is a bit of warning before an RC is built. We normally release as a group, not as a lone ranger that doesn't care about the rest of the devs and is just going to make his RC at the drop of a hat with no warning or care what others think. - Mark On Apr 17, 2013, at 10:13 AM, Simon Willnauer wrote: > dude you had 12 days since rob send the note to the list. what are you > talking about? > > > > On Wed, Apr 17, 2013 at 4:07 PM, Mark Miller wrote: > > On Apr 17, 2013, at 10:04 AM, Simon Willnauer > wrote: > > > honestly I don't think we should push in last minute changes by saying "oh > > I will wait 2 days" We should release early and often as we do and fixes > > will make it to the next release right next month. > > Review and bug fixes are not last minute changes. Pretending we should not > focus on a release is ridicules. I want to release quality software, not > hurried crap. > > > Robert say I will do one in the next 2 weeks unless somebody is quicker. As > > always folks say we release once somebody volunteers. I don't know how > > often I had something in the pipeline that I wanted in the release and I as > > often we had this discussion. The 4.2 release was not even announced before > > the RC was up and I think this is how it should be. You can do another > > release soon in about 3 week or whatever. > > Dude, asking for a small amount of planning on a release seems very > reasonable. Wake up today and surprise "release" is ridiculous. Not even a > day or two notice? > > If this is how it goes, I'm happy to just randomly start tossing up RC all > the time with no discussion or notice to the list. > > I'll probably toss one up a few days after you do after I do my review. > > - Mark > > > > > simon > > > > > > On Wed, Apr 17, 2013 at 3:56 PM, Mark Miller wrote: > > How about a short heads up so that people working on 4.3 issues can > > actually wrap up? I know I have review I want to finish before 4.3 at > > least. > > > > Robert gave a warning of 2 weeks, then less than a week later you say, I'm > > rolling now? Can't we at least have a day or two notice to wrap? > > > > - Mark > > > > On Apr 17, 2013, at 5:16 AM, Simon Willnauer > > wrote: > > > > > Folks, > > > > > > I started a release branch for Lucene / Solr 4.3 > > > https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/ > > > I will update the 4.x branch now and build the first RC > > > > > > simon > > > > > > > > > On Thu, Apr 11, 2013 at 1:21 AM, Robert Muir wrote: > > > 4.3 is looking good already. If nobody has spun a release candidate in > > > two weeks, I will. > > > > > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.3
dude you had 12 days since rob send the note to the list. what are you talking about? On Wed, Apr 17, 2013 at 4:07 PM, Mark Miller wrote: > > On Apr 17, 2013, at 10:04 AM, Simon Willnauer > wrote: > > > honestly I don't think we should push in last minute changes by saying > "oh I will wait 2 days" We should release early and often as we do and > fixes will make it to the next release right next month. > > Review and bug fixes are not last minute changes. Pretending we should not > focus on a release is ridicules. I want to release quality software, not > hurried crap. > > > Robert say I will do one in the next 2 weeks unless somebody is quicker. > As always folks say we release once somebody volunteers. I don't know how > often I had something in the pipeline that I wanted in the release and I as > often we had this discussion. The 4.2 release was not even announced before > the RC was up and I think this is how it should be. You can do another > release soon in about 3 week or whatever. > > Dude, asking for a small amount of planning on a release seems very > reasonable. Wake up today and surprise "release" is ridiculous. Not even a > day or two notice? > > If this is how it goes, I'm happy to just randomly start tossing up RC all > the time with no discussion or notice to the list. > > I'll probably toss one up a few days after you do after I do my review. > > - Mark > > > > > simon > > > > > > On Wed, Apr 17, 2013 at 3:56 PM, Mark Miller > wrote: > > How about a short heads up so that people working on 4.3 issues can > actually wrap up? I know I have review I want to finish before 4.3 at > least. > > > > Robert gave a warning of 2 weeks, then less than a week later you say, > I'm rolling now? Can't we at least have a day or two notice to wrap? > > > > - Mark > > > > On Apr 17, 2013, at 5:16 AM, Simon Willnauer > wrote: > > > > > Folks, > > > > > > I started a release branch for Lucene / Solr 4.3 > https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/ > > > I will update the 4.x branch now and build the first RC > > > > > > simon > > > > > > > > > On Thu, Apr 11, 2013 at 1:21 AM, Robert Muir wrote: > > > 4.3 is looking good already. If nobody has spun a release candidate in > two weeks, I will. > > > > > > > > > > > >
Re: 4.3
On Apr 17, 2013, at 10:04 AM, Simon Willnauer wrote: > honestly I don't think we should push in last minute changes by saying "oh I > will wait 2 days" We should release early and often as we do and fixes will > make it to the next release right next month. Review and bug fixes are not last minute changes. Pretending we should not focus on a release is ridicules. I want to release quality software, not hurried crap. > Robert say I will do one in the next 2 weeks unless somebody is quicker. As > always folks say we release once somebody volunteers. I don't know how often > I had something in the pipeline that I wanted in the release and I as often > we had this discussion. The 4.2 release was not even announced before the RC > was up and I think this is how it should be. You can do another release soon > in about 3 week or whatever. Dude, asking for a small amount of planning on a release seems very reasonable. Wake up today and surprise "release" is ridiculous. Not even a day or two notice? If this is how it goes, I'm happy to just randomly start tossing up RC all the time with no discussion or notice to the list. I'll probably toss one up a few days after you do after I do my review. - Mark > > simon > > > On Wed, Apr 17, 2013 at 3:56 PM, Mark Miller wrote: > How about a short heads up so that people working on 4.3 issues can actually > wrap up? I know I have review I want to finish before 4.3 at least. > > Robert gave a warning of 2 weeks, then less than a week later you say, I'm > rolling now? Can't we at least have a day or two notice to wrap? > > - Mark > > On Apr 17, 2013, at 5:16 AM, Simon Willnauer > wrote: > > > Folks, > > > > I started a release branch for Lucene / Solr 4.3 > > https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/ > > I will update the 4.x branch now and build the first RC > > > > simon > > > > > > On Thu, Apr 11, 2013 at 1:21 AM, Robert Muir wrote: > > 4.3 is looking good already. If nobody has spun a release candidate in two > > weeks, I will. > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.3
honestly I don't think we should push in last minute changes by saying "oh I will wait 2 days" We should release early and often as we do and fixes will make it to the next release right next month. Robert say I will do one in the next 2 weeks unless somebody is quicker. As always folks say we release once somebody volunteers. I don't know how often I had something in the pipeline that I wanted in the release and I as often we had this discussion. The 4.2 release was not even announced before the RC was up and I think this is how it should be. You can do another release soon in about 3 week or whatever. simon On Wed, Apr 17, 2013 at 3:56 PM, Mark Miller wrote: > How about a short heads up so that people working on 4.3 issues can > actually wrap up? I know I have review I want to finish before 4.3 at > least. > > Robert gave a warning of 2 weeks, then less than a week later you say, I'm > rolling now? Can't we at least have a day or two notice to wrap? > > - Mark > > On Apr 17, 2013, at 5:16 AM, Simon Willnauer > wrote: > > > Folks, > > > > I started a release branch for Lucene / Solr 4.3 > https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/ > > I will update the 4.x branch now and build the first RC > > > > simon > > > > > > On Thu, Apr 11, 2013 at 1:21 AM, Robert Muir wrote: > > 4.3 is looking good already. If nobody has spun a release candidate in > two weeks, I will. > > > > > >
[jira] [Commented] (SOLR-4661) Index Version & Gen look out of sync in replication UI when master searcher uses older commit then what is replicatable
[
https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634041#comment-13634041
]
Joel Bernstein commented on SOLR-4661:
--
I'm concerned about the empty commits opening a new index searcher on the
slave. In my testing I found that empty commits do not cause a new searcher to
open on master, but do open a new searcher on the slave. This feels like a bug.
I'll investigate further. Wondering what peoples thoughts are on this?
> Index Version & Gen look out of sync in replication UI when master searcher
> uses older commit then what is replicatable
> ---
>
> Key: SOLR-4661
> URL: https://issues.apache.org/jira/browse/SOLR-4661
> Project: Solr
> Issue Type: Bug
> Components: replication (java), web gui
>Affects Versions: 4.2
> Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7
>Reporter: Aditya
> Labels: gui, replication, web
> Attachments: hoss_test.zip, IndexVersionSyncIssue.jpg,
> SOLR-4661.patch, SOLR-4661.patch, SOLR-4661.patch
>
>
> the ReplicationHandler (and the replication admin UI screen) report the index
> version & gen for the master based on what commit point is currently open for
> searching -- but this is not necessarily the most recent commit point
> available for replication.
> Thus, it can appear that a slave has "gotten ahead" of the master, if there
> are "empty commits" (because of reader reopening shotcuts) or commits using
> openSearcher=false.
> We need to add additional data to help make it clear there is no actual
> problem in this sitation.
> Summary of original bug report..
> {panel}
> Index and Gen number on Slave is higher than master.
> If you apply commit on master with no pending docs then the commit time stamp
> and gen is incremented. When Slaves polls master for replication it see the
> index version difference and starts replicating but all files are skipped.
> On Admin UI (on Slaves) the version number displayed for master is old where
> as for slave is the latest which is higher than master.
> Below is the response from master (/replication?command=details) where i see
> two different Version an Gen numbers. This creates confusion of having
> version out of sync, though its not.
> ...
> {panel}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.3
How about a short heads up so that people working on 4.3 issues can actually wrap up? I know I have review I want to finish before 4.3 at least. Robert gave a warning of 2 weeks, then less than a week later you say, I'm rolling now? Can't we at least have a day or two notice to wrap? - Mark On Apr 17, 2013, at 5:16 AM, Simon Willnauer wrote: > Folks, > > I started a release branch for Lucene / Solr 4.3 > https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/ > I will update the 4.x branch now and build the first RC > > simon > > > On Thu, Apr 11, 2013 at 1:21 AM, Robert Muir wrote: > 4.3 is looking good already. If nobody has spun a release candidate in two > weeks, I will. > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
