[jira] [Commented] (SOLR-4629) Stronger standard replication testing.
[ https://issues.apache.org/jira/browse/SOLR-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609952#comment-13609952 ] Mark Miller commented on SOLR-4629: --- I added version checking to one of the configuration tests and a new test. The new test will do n loops of: add random number of docs to master commit randomly update conf file or not slave calls replicate compare doc count compare versions > Stronger standard replication testing. > -- > > Key: SOLR-4629 > URL: https://issues.apache.org/jira/browse/SOLR-4629 > Project: Solr > Issue Type: Test > Components: replication (java) >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.3, 5.0, 4.2.1 > > > I added to these tests recently, but there is a report on the list indicating > we may still be missing something. Most reports have been positive so far > after the 4.2 fixes, but I'd feel better after adding some more testing. -- 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-3706) Ship setup to log with log4j.
[ https://issues.apache.org/jira/browse/SOLR-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609938#comment-13609938 ] Mark Miller commented on SOLR-3706: --- bq. My question was only about the slf4j-api.jar file not any of the implementation jars I believe others have reported you cannot mix and match this way. I think that makes sense given the different class loaders that would be involved and how jetty will use slf4j as well. bq. If we don't include the -api.jar and there is no logging configured in the container it will crash with a ClassNotFound exception. If we add the -api.jar file it will write a line to stdout and stderr that say "no logging framework found" and then hide all logging messages. (this is the default slf4j behavior) I think if we can do something more explicit, that would be very helpful, but I think we are working from the classnotfound base point, because I don't think we can mix. > Ship setup to log with log4j. > - > > Key: SOLR-3706 > URL: https://issues.apache.org/jira/browse/SOLR-3706 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.3, 5.0 > > Attachments: SOLR-3706.patch, SOLR-3706-solr-log4j.patch, > SOLR-3706-solr-log4j.patch > > > Currently we default to java util logging and it's terrible in my opinion. > *It's simple built in logger is a 2 line logger. > *You have to jump through hoops to use your own custom formatter with jetty - > either putting your class in the start.jar or other pain in the butt > solutions. > *It can't roll files by date out of the box. > I'm sure there are more issues, but those are the ones annoying me now. We > should switch to log4j - it's much nicer and it's easy to get a nice single > line format and roll by date, etc. > If someone wants to use JUL they still can - but at least users could start > with something decent. -- 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-3706) Ship setup to log with log4j.
[ https://issues.apache.org/jira/browse/SOLR-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609931#comment-13609931 ] Ryan McKinley commented on SOLR-3706: - My question was only about the slf4j-api.jar file *not* any of the implementation jars If we don't include the -api.jar and there is no logging configured in the container it will crash with a ClassNotFound exception. If we add the -api.jar file it will write a line to stdout and stderr that say "no logging framework found" and then hide all logging messages. (this is the default slf4j behavior) > Ship setup to log with log4j. > - > > Key: SOLR-3706 > URL: https://issues.apache.org/jira/browse/SOLR-3706 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.3, 5.0 > > Attachments: SOLR-3706.patch, SOLR-3706-solr-log4j.patch, > SOLR-3706-solr-log4j.patch > > > Currently we default to java util logging and it's terrible in my opinion. > *It's simple built in logger is a 2 line logger. > *You have to jump through hoops to use your own custom formatter with jetty - > either putting your class in the start.jar or other pain in the butt > solutions. > *It can't roll files by date out of the box. > I'm sure there are more issues, but those are the ones annoying me now. We > should switch to log4j - it's much nicer and it's easy to get a nice single > line format and roll by date, etc. > If someone wants to use JUL they still can - but at least users could start > with something decent. -- 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-3706) Ship setup to log with log4j.
[ https://issues.apache.org/jira/browse/SOLR-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609919#comment-13609919 ] Mark Miller commented on SOLR-3706: --- It's a much better model really - it also lets jetty hook into the logging right away (or tomcat or whatever you container). Tons of upsides. Logging freedom. Finally. Yay. bq. It might be a good idea to have a very early classloader check in SolrDispatchFilter that checks if SLF4J is there and if not then gives you a very helpful message to remedy it – i.e. you need to place SLF4J jars in your app-server somewhere or re-pack the WAR with them. You bring up a good point - we should look at that and see how friendly we can make it. > Ship setup to log with log4j. > - > > Key: SOLR-3706 > URL: https://issues.apache.org/jira/browse/SOLR-3706 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.3, 5.0 > > Attachments: SOLR-3706.patch, SOLR-3706-solr-log4j.patch, > SOLR-3706-solr-log4j.patch > > > Currently we default to java util logging and it's terrible in my opinion. > *It's simple built in logger is a 2 line logger. > *You have to jump through hoops to use your own custom formatter with jetty - > either putting your class in the start.jar or other pain in the butt > solutions. > *It can't roll files by date out of the box. > I'm sure there are more issues, but those are the ones annoying me now. We > should switch to log4j - it's much nicer and it's easy to get a nice single > line format and roll by date, etc. > If someone wants to use JUL they still can - but at least users could start > with something decent. -- 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] (LUCENE-4752) Merge segments to sort them
[ https://issues.apache.org/jira/browse/LUCENE-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609920#comment-13609920 ] Shai Erera commented on LUCENE-4752: Looks good! I like OneMerge.getMergeReaders() -- it's one way to customize your readers as they are merged. This has been asked on the user list a couple times that I remember. Adrien, you didn't put your name in the CHANGES entry :). +1 to commit. > Merge segments to sort them > --- > > Key: LUCENE-4752 > URL: https://issues.apache.org/jira/browse/LUCENE-4752 > Project: Lucene - Core > Issue Type: New Feature > Components: core/index >Reporter: David Smiley >Assignee: Adrien Grand > Attachments: LUCENE-4752.patch, LUCENE-4752.patch, LUCENE-4752.patch, > LUCENE-4752.patch, LUCENE-4752.patch, LUCENE-4752.patch, LUCENE-4752.patch, > natural_10M_ingestion.log, sorting_10M_ingestion.log > > > It would be awesome if Lucene could write the documents out in a segment > based on a configurable order. This of course applies to merging segments > to. The benefit is increased locality on disk of documents that are likely to > be accessed together. This often applies to documents near each other in > time, but also spatially. -- 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-3706) Ship setup to log with log4j.
[ https://issues.apache.org/jira/browse/SOLR-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609914#comment-13609914 ] David Smiley commented on SOLR-3706: As long it's _also_ easy to handle an SLF4J-less war in Tomcat, then I think it's fine too. Nonetheless this is going to be a new thing a deployer of Solr needs to check the box in their checklist. It might be a good idea to have a very early classloader check in SolrDispatchFilter that checks if SLF4J is there and if not then gives you a very helpful message to remedy it -- i.e. you need to place SLF4J jars in your app-server somewhere or re-pack the WAR with them. > Ship setup to log with log4j. > - > > Key: SOLR-3706 > URL: https://issues.apache.org/jira/browse/SOLR-3706 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.3, 5.0 > > Attachments: SOLR-3706.patch, SOLR-3706-solr-log4j.patch, > SOLR-3706-solr-log4j.patch > > > Currently we default to java util logging and it's terrible in my opinion. > *It's simple built in logger is a 2 line logger. > *You have to jump through hoops to use your own custom formatter with jetty - > either putting your class in the start.jar or other pain in the butt > solutions. > *It can't roll files by date out of the box. > I'm sure there are more issues, but those are the ones annoying me now. We > should switch to log4j - it's much nicer and it's easy to get a nice single > line format and roll by date, etc. > If someone wants to use JUL they still can - but at least users could start > with something decent. -- 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] (LUCENE-4644) Implement spatial WITHIN query for RecursivePrefixTree
[ https://issues.apache.org/jira/browse/LUCENE-4644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609906#comment-13609906 ] David Smiley commented on LUCENE-4644: -- It just dawned upon me that this limitation of Within finding false-positives could be remedied right now, without waiting for the faster approach in LUCENE-4869. I see 3 configurable options: # As indicated in earlier discussion on this issue on the first comment, it can visit all regions outside the query shape and mark those docs for exclusion in the final results. Yes this would be slow but it would work, and it would be particularly easy to implement as my existing code would only need a small modification. So in summary, this approach can be addressed now, it's slow, it works. # Allow a configurable buffer where the user wants Within, but is willing to disregard any regions that might be outside of that buffer that would create a false-positive match. Is this useful? It's easy to add to the existing code which is already doing shape buffering. # The approach in LUCENE-4869: filter false-positives out using a representative point from each disjoint piece of an indexed shape that is saved at index time. This will be fast but will require memory and it'll take some time to get there based on where the APIs are at now. > Implement spatial WITHIN query for RecursivePrefixTree > -- > > Key: LUCENE-4644 > URL: https://issues.apache.org/jira/browse/LUCENE-4644 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/spatial >Reporter: David Smiley >Assignee: David Smiley > Attachments: > LUCENE-4644_Spatial_Within_predicate_for_RecursivePrefixTree.patch > > -- 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-4629) Stronger standard replication testing.
[ https://issues.apache.org/jira/browse/SOLR-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609904#comment-13609904 ] Commit Tag Bot commented on SOLR-4629: -- [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1459620 SOLR-4629: More Replication testing. > Stronger standard replication testing. > -- > > Key: SOLR-4629 > URL: https://issues.apache.org/jira/browse/SOLR-4629 > Project: Solr > Issue Type: Test > Components: replication (java) >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.3, 5.0, 4.2.1 > > > I added to these tests recently, but there is a report on the list indicating > we may still be missing something. Most reports have been positive so far > after the 4.2 fixes, but I'd feel better after adding some more testing. -- 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-4629) Stronger standard replication testing.
[ https://issues.apache.org/jira/browse/SOLR-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609891#comment-13609891 ] Commit Tag Bot commented on SOLR-4629: -- [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1459618 SOLR-4629: More Replication testing. > Stronger standard replication testing. > -- > > Key: SOLR-4629 > URL: https://issues.apache.org/jira/browse/SOLR-4629 > Project: Solr > Issue Type: Test > Components: replication (java) >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.3, 5.0, 4.2.1 > > > I added to these tests recently, but there is a report on the list indicating > we may still be missing something. Most reports have been positive so far > after the 4.2 fixes, but I'd feel better after adding some more testing. -- 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-4624) CachingDirectoryFactory does not need to support forceNew any longer and it may be causing a missing close directory bug.
[ https://issues.apache.org/jira/browse/SOLR-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-4624. --- Resolution: Fixed > CachingDirectoryFactory does not need to support forceNew any longer and it > may be causing a missing close directory bug. > - > > Key: SOLR-4624 > URL: https://issues.apache.org/jira/browse/SOLR-4624 > Project: Solr > Issue Type: Task >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.3, 5.0, 4.2.1 > > > Our forceNew uses were essentially hacks that have been replaced with correct > solutions. We should remove it. -- 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-3706) Ship setup to log with log4j.
[ https://issues.apache.org/jira/browse/SOLR-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609865#comment-13609865 ] Shawn Heisey commented on SOLR-3706: bq. Do we want slf4j-api in the .war or nothing? I think nothing is OK (as you have it) I favor having none of the slf4j jars in the war. If logging jars in lib/ext will be the new standard, it's better to have all the related jars there and none of them in the war. > Ship setup to log with log4j. > - > > Key: SOLR-3706 > URL: https://issues.apache.org/jira/browse/SOLR-3706 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.3, 5.0 > > Attachments: SOLR-3706.patch, SOLR-3706-solr-log4j.patch, > SOLR-3706-solr-log4j.patch > > > Currently we default to java util logging and it's terrible in my opinion. > *It's simple built in logger is a 2 line logger. > *You have to jump through hoops to use your own custom formatter with jetty - > either putting your class in the start.jar or other pain in the butt > solutions. > *It can't roll files by date out of the box. > I'm sure there are more issues, but those are the ones annoying me now. We > should switch to log4j - it's much nicer and it's easy to get a nice single > line format and roll by date, etc. > If someone wants to use JUL they still can - but at least users could start > with something decent. -- 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] (LUCENE-4571) speedup disjunction with minShouldMatch
[
https://issues.apache.org/jira/browse/LUCENE-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609821#comment-13609821
]
Robert Muir commented on LUCENE-4571:
-
Also for the record, the previous "for reference patch" (20/Mar/13 13:54)
passes the new test (which doesnt check scores yet, just documents)
So its just the newest patch with a bug. I'm gonna play and see if I can spot
it... because I really want to benchmark this thing!
> speedup disjunction with minShouldMatch
>
>
> Key: LUCENE-4571
> URL: https://issues.apache.org/jira/browse/LUCENE-4571
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: 4.1
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-4571.patch, LUCENE-4571.patch, LUCENE-4571.patch,
> LUCENE-4571.patch, LUCENE-4571.patch
>
>
> even minShouldMatch is supplied to DisjunctionSumScorer it enumerates whole
> disjunction, and verifies minShouldMatch condition [on every
> doc|https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/search/DisjunctionSumScorer.java#L70]:
> {code}
> public int nextDoc() throws IOException {
> assert doc != NO_MORE_DOCS;
> while(true) {
> while (subScorers[0].docID() == doc) {
> if (subScorers[0].nextDoc() != NO_MORE_DOCS) {
> heapAdjust(0);
> } else {
> heapRemoveRoot();
> if (numScorers < minimumNrMatchers) {
> return doc = NO_MORE_DOCS;
> }
> }
> }
> afterNext();
> if (nrMatchers >= minimumNrMatchers) {
> break;
> }
> }
>
> return doc;
> }
> {code}
> [~spo] proposes (as well as I get it) to pop nrMatchers-1 scorers from the
> heap first, and then push them back advancing behind that top doc. For me the
> question no.1 is there a performance test for minShouldMatch constrained
> disjunction.
--
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-4629) Stronger standard replication testing.
Mark Miller created SOLR-4629: - Summary: Stronger standard replication testing. Key: SOLR-4629 URL: https://issues.apache.org/jira/browse/SOLR-4629 Project: Solr Issue Type: Test Components: replication (java) Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.3, 5.0, 4.2.1 I added to these tests recently, but there is a report on the list indicating we may still be missing something. Most reports have been positive so far after the 4.2 fixes, but I'd feel better after adding some more testing. -- 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
Test Framework Logging Stack Traces
There are some fails like the below where they are not logged by an internal component, just caught as a thrown exception. The one below has a caused by exception and I'd love to know what it is, but it cuts off with "... 46 more". I pulled this from some jenkins output. Anyone know if there is a way we can force the entire stack trace no matter what or is this some hard limitation we have? I always need the caused by and we can have some pretty deep stacks. - Mark [junit4:junit4]> Throwable #1: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: https://127.0.0.1:36643/solr [junit4:junit4]>at __randomizedtesting.SeedInfo.seed([595EC9D8441A026A:B2887C7C3F5D879]:0) [junit4:junit4]>at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:416) [junit4:junit4]>at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:181) [junit4:junit4]>at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:117) [junit4:junit4]>at org.apache.solr.client.solrj.SolrServer.commit(SolrServer.java:168) [junit4:junit4]>at org.apache.solr.client.solrj.SolrServer.commit(SolrServer.java:146) [junit4:junit4]>at org.apache.solr.client.solrj.TestBatchUpdate.doIt(TestBatchUpdate.java:130) [junit4:junit4]>at org.apache.solr.client.solrj.TestBatchUpdate.testWithBinary(TestBatchUpdate.java:62) [junit4:junit4]>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit4:junit4]>at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [junit4:junit4]>at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [junit4:junit4]>at java.lang.reflect.Method.invoke(Method.java:601) [junit4:junit4]>at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) [junit4:junit4]>at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) [junit4:junit4]>at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) [junit4:junit4]>at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) [junit4:junit4]>at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) [junit4:junit4]>at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) [junit4:junit4]>at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) [junit4:junit4]>at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) [junit4:junit4]>at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) [junit4:junit4]>at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) [junit4:junit4]>at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) [junit4:junit4]>at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) [junit4:junit4]>at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) [junit4:junit4]>at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) [junit4:junit4]>at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) [junit4:junit4]>at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) [junit4:junit4]>at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) [junit4:junit4]>at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) [junit4:junit4]>at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) [junit4:junit4]>at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) [junit4:junit4]>at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) [junit4:junit4]>at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) [junit4:junit4]>at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) [junit4:junit4]>at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) [junit4:junit4]>at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) [junit4:junit4]>at
[jira] [Updated] (SOLR-4628) Solr 4.2 Admin UI
[ https://issues.apache.org/jira/browse/SOLR-4628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] cozybreeze updated SOLR-4628: - Environment: Intel PC + Win7 64 + Tomcat 6 + 19-inch 4:3 screen (was: Intel PC + Win7 64 + Tomcat 6) > Solr 4.2 Admin UI > - > > Key: SOLR-4628 > URL: https://issues.apache.org/jira/browse/SOLR-4628 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.2 > Environment: Intel PC + Win7 64 + Tomcat 6 + 19-inch 4:3 screen >Reporter: cozybreeze > Labels: 4.2, admin, gui, solr > > The new Admin web GUI has too-compact column for normal-width screen, e.g. in > the dashboard, if the directory is a long path, it will suppress the display > and replace the trailing part with '...' and there is no way to see the full > path. -- 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-4628) Solr 4.2 Admin UI
cozybreeze created SOLR-4628: Summary: Solr 4.2 Admin UI Key: SOLR-4628 URL: https://issues.apache.org/jira/browse/SOLR-4628 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.2 Environment: Intel PC + Win7 64 + Tomcat 6 Reporter: cozybreeze The new Admin web GUI has too-compact column for normal-width screen, e.g. in the dashboard, if the directory is a long path, it will suppress the display and replace the trailing part with '...' and there is no way to see the full path. -- 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] (LUCENE-4861) can we use a single PostingsHighlighter for both whole and snippet highlighting?
[ https://issues.apache.org/jira/browse/LUCENE-4861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609798#comment-13609798 ] Robert Muir commented on LUCENE-4861: - I fixed this BreakIterator. I will wait on LUCENE-4860 to be committed first, then I think this issue is easy: we can just make it public and the API will be simple. > can we use a single PostingsHighlighter for both whole and snippet > highlighting? > > > Key: LUCENE-4861 > URL: https://issues.apache.org/jira/browse/LUCENE-4861 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0, 4.3 > > > Right now, because we pass the BreakIterator to the ctor, you have to make > two instances if you sometimes want whole and sometimes want snippets. > But I think this is a fairly common use case, eg I want entire title field > (with matches highlighted) but I want body field (snippets + highlights). It > would be nice to have this work with a single instance ... -- 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] (LUCENE-4860) PostingsHighlighter should pass field name to PassageFormatter.format?
[ https://issues.apache.org/jira/browse/LUCENE-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609769#comment-13609769 ] Robert Muir commented on LUCENE-4860: - +1 > PostingsHighlighter should pass field name to PassageFormatter.format? > -- > > Key: LUCENE-4860 > URL: https://issues.apache.org/jira/browse/LUCENE-4860 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0, 4.3 > > Attachments: LUCENE-4860.patch, LUCENE-4860.patch, LUCENE-4860.patch, > LUCENE-4860.patch > > > If the app needs to render different fields (eg multi-valued vs > single-valued) differently it's tricky now. > You can do Passage[0].getMatchTerms()[0].field(), but then that doesn't work > if that field hit the empty highlight. > I think we should pass the fieldName to format directly? And then maybe > change getMatchTerms() to return BytesRef[] instead (the field name is > redundant: they are all the same for all passages passed to format). -- 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] (LUCENE-4864) Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 only)
[ https://issues.apache.org/jira/browse/LUCENE-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609714#comment-13609714 ] Michael Poindexter commented on LUCENE-4864: bq. If this is only gonna help Windows 32 (ancient platform by now?) ... we should limit its visibility somehow I think. Perhaps you are right. I implemented this stuff because I am doing some "interesting" things with directories, and the inability to delete open files on Windows boxes was causing me some trouble. I really want to compare this vs. NIOFS on Windows, since I'll probably end up using one of those because as Uwe pointed out mmap'ing files prevents them from being deleted. Seems like this might still be useful for anyone on Win 32, or does not want to be reflecting into JRE core code to clean up buffers like MMap directory does (I see why it does it, but I'm still a bit wary of doing something like this in my app...my indexes are fairly small, and search is a small enough part of what my app does that I'm willing to take a reasonable performance hit to avoid it). > Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 > only) > --- > > Key: LUCENE-4864 > URL: https://issues.apache.org/jira/browse/LUCENE-4864 > Project: Lucene - Core > Issue Type: Improvement > Components: core/store >Affects Versions: 5.0 >Reporter: Michael Poindexter > Attachments: LUCENE-4864.patch, LUCENE-4864.patch > > > On LUCENE-4848 a new directory implementation was proposed that uses > AsyncFileChannel to make a sync-less directory implementation (only needed > for IndexInput). The problem on Windows is that positional reads are > impossible without overlapping (async) I/O, so FileChannel in the JDK has to > syncronize all reads, because they consist of an atomic seek and atomic read. > AsyncFSDirectoty would not have this issue, but has to take care of thread > management, because you need a separate thread to get notified when the read > is done. This involves overhead, but might still be better than the > synchronization. -- 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] (LUCENE-4864) Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 only)
[ https://issues.apache.org/jira/browse/LUCENE-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609698#comment-13609698 ] Michael Poindexter commented on LUCENE-4864: On any platform other than Windows (at least in JDK7, haven't checked JDK8 prereleases) the AsynchronousFileChannel is quite unlikely to be faster since it's just a normal NIO read + the cost of notifying the future. On Windows it should theoretically be better as long as multiple threads are being used for reads (perhaps with tweaking the ExecutorService passed to it) since it uses overlapped IO. For the case of single threaded reads it is again likely to be roughly the same as SimpleFSDirectory. I'd love to run some comparisons on a Windows platform if someone can point out to me the best way to do so. > Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 > only) > --- > > Key: LUCENE-4864 > URL: https://issues.apache.org/jira/browse/LUCENE-4864 > Project: Lucene - Core > Issue Type: Improvement > Components: core/store >Affects Versions: 5.0 >Reporter: Michael Poindexter > Attachments: LUCENE-4864.patch, LUCENE-4864.patch > > > On LUCENE-4848 a new directory implementation was proposed that uses > AsyncFileChannel to make a sync-less directory implementation (only needed > for IndexInput). The problem on Windows is that positional reads are > impossible without overlapping (async) I/O, so FileChannel in the JDK has to > syncronize all reads, because they consist of an atomic seek and atomic read. > AsyncFSDirectoty would not have this issue, but has to take care of thread > management, because you need a separate thread to get notified when the read > is done. This involves overhead, but might still be better than the > synchronization. -- 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-4624) CachingDirectoryFactory does not need to support forceNew any longer and it may be causing a missing close directory bug.
[ https://issues.apache.org/jira/browse/SOLR-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609677#comment-13609677 ] Commit Tag Bot commented on SOLR-4624: -- [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1459570 SOLR-4624: remove leftover forceNew params. SOLR-4626: getIndexWriter(null) should also respect pauseWriter. > CachingDirectoryFactory does not need to support forceNew any longer and it > may be causing a missing close directory bug. > - > > Key: SOLR-4624 > URL: https://issues.apache.org/jira/browse/SOLR-4624 > Project: Solr > Issue Type: Task >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.3, 5.0, 4.2.1 > > > Our forceNew uses were essentially hacks that have been replaced with correct > solutions. We should remove it. -- 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-4626) TestCoreContainer Fail: AlreadyClosedException: this IndexWriter is closed
[ https://issues.apache.org/jira/browse/SOLR-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609676#comment-13609676 ] Commit Tag Bot commented on SOLR-4626: -- [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1459571 SOLR-4624: remove leftover forceNew params. SOLR-4626: getIndexWriter(null) should also respect pauseWriter. > TestCoreContainer Fail: AlreadyClosedException: this IndexWriter is closed > -- > > Key: SOLR-4626 > URL: https://issues.apache.org/jira/browse/SOLR-4626 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.3, 5.0, 4.2.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
[jira] [Commented] (SOLR-4626) TestCoreContainer Fail: AlreadyClosedException: this IndexWriter is closed
[ https://issues.apache.org/jira/browse/SOLR-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609678#comment-13609678 ] Commit Tag Bot commented on SOLR-4626: -- [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1459570 SOLR-4624: remove leftover forceNew params. SOLR-4626: getIndexWriter(null) should also respect pauseWriter. > TestCoreContainer Fail: AlreadyClosedException: this IndexWriter is closed > -- > > Key: SOLR-4626 > URL: https://issues.apache.org/jira/browse/SOLR-4626 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.3, 5.0, 4.2.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
[jira] [Commented] (SOLR-4624) CachingDirectoryFactory does not need to support forceNew any longer and it may be causing a missing close directory bug.
[ https://issues.apache.org/jira/browse/SOLR-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609675#comment-13609675 ] Commit Tag Bot commented on SOLR-4624: -- [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1459571 SOLR-4624: remove leftover forceNew params. SOLR-4626: getIndexWriter(null) should also respect pauseWriter. > CachingDirectoryFactory does not need to support forceNew any longer and it > may be causing a missing close directory bug. > - > > Key: SOLR-4624 > URL: https://issues.apache.org/jira/browse/SOLR-4624 > Project: Solr > Issue Type: Task >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.3, 5.0, 4.2.1 > > > Our forceNew uses were essentially hacks that have been replaced with correct > solutions. We should remove it. -- 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-4624) CachingDirectoryFactory does not need to support forceNew any longer and it may be causing a missing close directory bug.
[ https://issues.apache.org/jira/browse/SOLR-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-4624: -- Fix Version/s: 4.2.1 > CachingDirectoryFactory does not need to support forceNew any longer and it > may be causing a missing close directory bug. > - > > Key: SOLR-4624 > URL: https://issues.apache.org/jira/browse/SOLR-4624 > Project: Solr > Issue Type: Task >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.3, 5.0, 4.2.1 > > > Our forceNew uses were essentially hacks that have been replaced with correct > solutions. We should remove it. -- 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-4624) CachingDirectoryFactory does not need to support forceNew any longer and it may be causing a missing close directory bug.
[ https://issues.apache.org/jira/browse/SOLR-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609663#comment-13609663 ] Commit Tag Bot commented on SOLR-4624: -- [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1459567 SOLR-4624: CachingDirectoryFactory does not need to support forceNew any longer and it appears to be causing a missing close directory bug. forceNew is no longer respected and will be removed in 4.3. > CachingDirectoryFactory does not need to support forceNew any longer and it > may be causing a missing close directory bug. > - > > Key: SOLR-4624 > URL: https://issues.apache.org/jira/browse/SOLR-4624 > Project: Solr > Issue Type: Task >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.3, 5.0 > > > Our forceNew uses were essentially hacks that have been replaced with correct > solutions. We should remove it. -- 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-4627) Warmup queries don't work for grouping
Ricardo Merizalde created SOLR-4627: --- Summary: Warmup queries don't work for grouping Key: SOLR-4627 URL: https://issues.apache.org/jira/browse/SOLR-4627 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.1 Reporter: Ricardo Merizalde Priority: Minor Fix For: 4.1 When setting queries with the option group=true class QuerySenderListener doesn't process the document list. Hence, caches are not warmed. This can be fixed easily by updating the following to process GroupResponses // Retrieve the Document instances (not just the ids) to warm // the OS disk cache, and any Solr document cache. Only the top // level values in the NamedList are checked for DocLists. NamedList values = rsp.getValues(); for (int i=0; ihttp://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] (LUCENE-4860) PostingsHighlighter should pass field name to PassageFormatter.format?
[ https://issues.apache.org/jira/browse/LUCENE-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-4860: --- Attachment: LUCENE-4860.patch New patch, adding back lost assert in one test and adding back null check for the scorer... > PostingsHighlighter should pass field name to PassageFormatter.format? > -- > > Key: LUCENE-4860 > URL: https://issues.apache.org/jira/browse/LUCENE-4860 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0, 4.3 > > Attachments: LUCENE-4860.patch, LUCENE-4860.patch, LUCENE-4860.patch, > LUCENE-4860.patch > > > If the app needs to render different fields (eg multi-valued vs > single-valued) differently it's tricky now. > You can do Passage[0].getMatchTerms()[0].field(), but then that doesn't work > if that field hit the empty highlight. > I think we should pass the fieldName to format directly? And then maybe > change getMatchTerms() to return BytesRef[] instead (the field name is > redundant: they are all the same for all passages passed to format). -- 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-4624) CachingDirectoryFactory does not need to support forceNew any longer and it may be causing a missing close directory bug.
[ https://issues.apache.org/jira/browse/SOLR-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609637#comment-13609637 ] Commit Tag Bot commented on SOLR-4624: -- [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1459565 SOLR-4624: CachingDirectoryFactory does not need to support forceNew any longer and it appears to be causing a missing close directory bug. forceNew is no longer respected and will be removed in 4.3. > CachingDirectoryFactory does not need to support forceNew any longer and it > may be causing a missing close directory bug. > - > > Key: SOLR-4624 > URL: https://issues.apache.org/jira/browse/SOLR-4624 > Project: Solr > Issue Type: Task >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.3, 5.0 > > > Our forceNew uses were essentially hacks that have been replaced with correct > solutions. We should remove it. -- 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] [Comment Edited] (LUCENE-4864) Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 only)
[ https://issues.apache.org/jira/browse/LUCENE-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609619#comment-13609619 ] Uwe Schindler edited comment on LUCENE-4864 at 3/21/13 10:37 PM: - I would like to see a comparison between SimpleFSDir on Windows (or Linux) and this one. If its slower we can close this issue as won't fix and better dont't provide this directory at all. According to Michael, he just implemented what the Sun bug tracker suggested: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6265734 (see also LUCENE-753 and http://wiki.apache.org/lucene-java/SunJavaBugs) Unfortunately I have no luceneutil working on windows, so I cannot test, too. was (Author: thetaphi): I would like to see a comparison between this one SimpleFSDir on Windows (or Linux) and this one. If its slower we can close this issue as won't fix and better dont't provide this directory at all. According to Michael, he just implemented what the Sun bug tracker suggested: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6265734 (see also LUCENE-753 and http://wiki.apache.org/lucene-java/SunJavaBugs) Unfortunately I have no luceneutil working on windows, so I cannot test, too. > Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 > only) > --- > > Key: LUCENE-4864 > URL: https://issues.apache.org/jira/browse/LUCENE-4864 > Project: Lucene - Core > Issue Type: Improvement > Components: core/store >Affects Versions: 5.0 >Reporter: Michael Poindexter > Attachments: LUCENE-4864.patch, LUCENE-4864.patch > > > On LUCENE-4848 a new directory implementation was proposed that uses > AsyncFileChannel to make a sync-less directory implementation (only needed > for IndexInput). The problem on Windows is that positional reads are > impossible without overlapping (async) I/O, so FileChannel in the JDK has to > syncronize all reads, because they consist of an atomic seek and atomic read. > AsyncFSDirectoty would not have this issue, but has to take care of thread > management, because you need a separate thread to get notified when the read > is done. This involves overhead, but might still be better than the > synchronization. -- 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: Lucene/Solr 4.2.1 - Last call for issue back porting.
I'll probably hold off on making an rc till the weekend given some things that have popped up. There is room to get stuff in. - Mark On Mar 19, 2013, at 3:04 PM, Mark Miller wrote: > Last call. > > - Mark Miller - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4864) Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 only)
[ https://issues.apache.org/jira/browse/LUCENE-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609619#comment-13609619 ] Uwe Schindler commented on LUCENE-4864: --- I would like to see a comparison between this one SimpleFSDir on Windows (or Linux) and this one. If its slower we can close this issue as won't fix and better dont't provide this directory at all. According to Michael, he just implemented what the Sun bug tracker suggested: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6265734 (see also LUCENE-753 and http://wiki.apache.org/lucene-java/SunJavaBugs) Unfortunately I have no luceneutil working on windows, so I cannot test, too. > Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 > only) > --- > > Key: LUCENE-4864 > URL: https://issues.apache.org/jira/browse/LUCENE-4864 > Project: Lucene - Core > Issue Type: Improvement > Components: core/store >Affects Versions: 5.0 >Reporter: Michael Poindexter > Attachments: LUCENE-4864.patch, LUCENE-4864.patch > > > On LUCENE-4848 a new directory implementation was proposed that uses > AsyncFileChannel to make a sync-less directory implementation (only needed > for IndexInput). The problem on Windows is that positional reads are > impossible without overlapping (async) I/O, so FileChannel in the JDK has to > syncronize all reads, because they consist of an atomic seek and atomic read. > AsyncFSDirectoty would not have this issue, but has to take care of thread > management, because you need a separate thread to get notified when the read > is done. This involves overhead, but might still be better than the > synchronization. -- 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] (LUCENE-4864) Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 only)
[ https://issues.apache.org/jira/browse/LUCENE-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609596#comment-13609596 ] Michael McCandless commented on LUCENE-4864: bq. Ah, did you test on windows? Sorry, no: I tested on Linux. I don't have a decent Windows box to run perf tests on ... If this is only gonna help Windows 32 (ancient platform by now?) ... we should limit its visibility somehow I think. > Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 > only) > --- > > Key: LUCENE-4864 > URL: https://issues.apache.org/jira/browse/LUCENE-4864 > Project: Lucene - Core > Issue Type: Improvement > Components: core/store >Affects Versions: 5.0 >Reporter: Michael Poindexter > Attachments: LUCENE-4864.patch, LUCENE-4864.patch > > > On LUCENE-4848 a new directory implementation was proposed that uses > AsyncFileChannel to make a sync-less directory implementation (only needed > for IndexInput). The problem on Windows is that positional reads are > impossible without overlapping (async) I/O, so FileChannel in the JDK has to > syncronize all reads, because they consist of an atomic seek and atomic read. > AsyncFSDirectoty would not have this issue, but has to take care of thread > management, because you need a separate thread to get notified when the read > is done. This involves overhead, but might still be better than the > synchronization. -- 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-4625) solr query parser should use multiplicative boosts and not apply phase slop to nested queries from a different qparser
[
https://issues.apache.org/jira/browse/SOLR-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609593#comment-13609593
]
Commit Tag Bot commented on SOLR-4625:
--
[branch_4x commit] Yonik Seeley
http://svn.apache.org/viewvc?view=revision&revision=1459541
SOLR-4625: fix boosts and phrase slops on sub parsers
> solr query parser should use multiplicative boosts and not apply phase slop
> to nested queries from a different qparser
> --
>
> Key: SOLR-4625
> URL: https://issues.apache.org/jira/browse/SOLR-4625
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Yonik Seeley
>Priority: Minor
> Fix For: 4.3, 5.0, 4.2.1
>
> Attachments: SOLR-4625.patch
>
>
> As reported by Michael Ryan,
> {code}
> _query_:"\"a b\"~2"~3 is parsed as "a b"~3
> {code}
> Additionally,
> {code}
> _query_:"x^2"^3 is parsed as x^3
> {code}
--
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] (LUCENE-4864) Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 only)
[ https://issues.apache.org/jira/browse/LUCENE-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609592#comment-13609592 ] Uwe Schindler commented on LUCENE-4864: --- Ah, did you test on windows? > Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 > only) > --- > > Key: LUCENE-4864 > URL: https://issues.apache.org/jira/browse/LUCENE-4864 > Project: Lucene - Core > Issue Type: Improvement > Components: core/store >Affects Versions: 5.0 >Reporter: Michael Poindexter > Attachments: LUCENE-4864.patch, LUCENE-4864.patch > > > On LUCENE-4848 a new directory implementation was proposed that uses > AsyncFileChannel to make a sync-less directory implementation (only needed > for IndexInput). The problem on Windows is that positional reads are > impossible without overlapping (async) I/O, so FileChannel in the JDK has to > syncronize all reads, because they consist of an atomic seek and atomic read. > AsyncFSDirectoty would not have this issue, but has to take care of thread > management, because you need a separate thread to get notified when the read > is done. This involves overhead, but might still be better than the > synchronization. -- 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] (LUCENE-4864) Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 only)
[ https://issues.apache.org/jira/browse/LUCENE-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609584#comment-13609584 ] Uwe Schindler commented on LUCENE-4864: --- Mike, the comparison should be between SimpleFSDir (which is the default on windows for 32 bit), NIOFSDir and this new async one. It is of course slower than MMap, that was expected. It is important to have hight concurrency. > Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 > only) > --- > > Key: LUCENE-4864 > URL: https://issues.apache.org/jira/browse/LUCENE-4864 > Project: Lucene - Core > Issue Type: Improvement > Components: core/store >Affects Versions: 5.0 >Reporter: Michael Poindexter > Attachments: LUCENE-4864.patch, LUCENE-4864.patch > > > On LUCENE-4848 a new directory implementation was proposed that uses > AsyncFileChannel to make a sync-less directory implementation (only needed > for IndexInput). The problem on Windows is that positional reads are > impossible without overlapping (async) I/O, so FileChannel in the JDK has to > syncronize all reads, because they consist of an atomic seek and atomic read. > AsyncFSDirectoty would not have this issue, but has to take care of thread > management, because you need a separate thread to get notified when the read > is done. This involves overhead, but might still be better than the > synchronization. -- 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] (LUCENE-4860) PostingsHighlighter should pass field name to PassageFormatter.format?
[ https://issues.apache.org/jira/browse/LUCENE-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-4860: --- Attachment: LUCENE-4860.patch Patch, creating & reusing the default PassageScorer/Formater once per highlight request ... I think it's ready. > PostingsHighlighter should pass field name to PassageFormatter.format? > -- > > Key: LUCENE-4860 > URL: https://issues.apache.org/jira/browse/LUCENE-4860 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0, 4.3 > > Attachments: LUCENE-4860.patch, LUCENE-4860.patch, LUCENE-4860.patch > > > If the app needs to render different fields (eg multi-valued vs > single-valued) differently it's tricky now. > You can do Passage[0].getMatchTerms()[0].field(), but then that doesn't work > if that field hit the empty highlight. > I think we should pass the fieldName to format directly? And then maybe > change getMatchTerms() to return BytesRef[] instead (the field name is > redundant: they are all the same for all passages passed to format). -- 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-4625) solr query parser should use multiplicative boosts and not apply phase slop to nested queries from a different qparser
[
https://issues.apache.org/jira/browse/SOLR-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-4625.
Resolution: Fixed
> solr query parser should use multiplicative boosts and not apply phase slop
> to nested queries from a different qparser
> --
>
> Key: SOLR-4625
> URL: https://issues.apache.org/jira/browse/SOLR-4625
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Yonik Seeley
>Priority: Minor
> Fix For: 4.3, 5.0, 4.2.1
>
> Attachments: SOLR-4625.patch
>
>
> As reported by Michael Ryan,
> {code}
> _query_:"\"a b\"~2"~3 is parsed as "a b"~3
> {code}
> Additionally,
> {code}
> _query_:"x^2"^3 is parsed as x^3
> {code}
--
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] (LUCENE-4864) Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 only)
[
https://issues.apache.org/jira/browse/LUCENE-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609573#comment-13609573
]
Michael McCandless commented on LUCENE-4864:
I ran a perf test with the full (wikimediumall) Wiki index, base = MMapDir,
comp = AsyncFSDir:
{noformat}
TaskQPS base StdDevQPS comp StdDev
Pct diff
AndHighLow 567.56 (0.8%) 69.48 (0.1%)
-87.8% ( -87% - -87%)
Respell 42.45 (4.0%)5.70 (0.2%)
-86.6% ( -87% - -85%)
LowPhrase 23.23 (1.4%)3.34 (0.1%)
-85.6% ( -85% - -85%)
Fuzzy2 54.01 (5.1%)8.60 (0.1%)
-84.1% ( -84% - -83%)
Fuzzy1 51.34 (4.3%)9.47 (0.2%)
-81.6% ( -82% - -80%)
LowSloppyPhrase 24.87 (1.0%)5.28 (0.0%)
-78.7% ( -79% - -78%)
AndHighMed 78.75 (0.5%) 19.49 (0.3%)
-75.2% ( -75% - -74%)
Wildcard 26.69 (2.7%)7.97 (0.3%)
-70.1% ( -71% - -69%)
HighPhrase 12.71 (7.2%)3.98 (1.0%)
-68.6% ( -71% - -65%)
MedPhrase 138.73 (6.5%) 51.65 (1.3%)
-62.8% ( -66% - -58%)
LowSpanNear8.73 (1.6%)3.28 (0.6%)
-62.5% ( -63% - -61%)
MedSloppyPhrase 27.76 (1.1%) 11.54 (0.3%)
-58.4% ( -59% - -57%)
MedTerm 64.12 (16.2%) 28.16 (3.2%)
-56.1% ( -64% - -43%)
AndHighHigh 19.39 (0.4%)8.78 (0.3%)
-54.7% ( -55% - -54%)
HighTerm 51.06 (16.8%) 23.16 (4.6%)
-54.6% ( -65% - -39%)
OrHighMed 28.74 (0.4%) 14.31 (0.6%)
-50.2% ( -51% - -49%)
OrHighLow 27.15 (0.2%) 13.69 (0.9%)
-49.6% ( -50% - -48%)
OrHighHigh 16.17 (0.2%)8.25 (0.8%)
-49.0% ( -49% - -48%)
HighSpanNear3.28 (0.6%)1.68 (0.6%)
-48.7% ( -49% - -47%)
MedSpanNear 29.58 (0.5%) 15.59 (0.8%)
-47.3% ( -48% - -46%)
HighSloppyPhrase0.78 (3.2%)0.42 (0.3%)
-46.3% ( -48% - -44%)
IntNRQ3.35 (2.8%)1.80 (1.0%)
-46.2% ( -48% - -43%)
Prefix3 18.97 (2.6%) 10.45 (1.1%)
-44.9% ( -47% - -42%)
LowTerm 312.34 (9.0%) 182.24 (2.8%)
-41.7% ( -49% - -32%)
{noformat}
I think the Future/wait is just too costly ...
> Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0
> only)
> ---
>
> Key: LUCENE-4864
> URL: https://issues.apache.org/jira/browse/LUCENE-4864
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/store
>Affects Versions: 5.0
>Reporter: Michael Poindexter
> Attachments: LUCENE-4864.patch, LUCENE-4864.patch
>
>
> On LUCENE-4848 a new directory implementation was proposed that uses
> AsyncFileChannel to make a sync-less directory implementation (only needed
> for IndexInput). The problem on Windows is that positional reads are
> impossible without overlapping (async) I/O, so FileChannel in the JDK has to
> syncronize all reads, because they consist of an atomic seek and atomic read.
> AsyncFSDirectoty would not have this issue, but has to take care of thread
> management, because you need a separate thread to get notified when the read
> is done. This involves overhead, but might still be better than the
> synchronization.
--
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] (LUCENE-4571) speedup disjunction with minShouldMatch
[
https://issues.apache.org/jira/browse/LUCENE-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609546#comment-13609546
]
Commit Tag Bot commented on LUCENE-4571:
[trunk commit] Robert Muir
http://svn.apache.org/viewvc?view=revision&revision=1459521
LUCENE-4571: improve minShouldMatch testing
> speedup disjunction with minShouldMatch
>
>
> Key: LUCENE-4571
> URL: https://issues.apache.org/jira/browse/LUCENE-4571
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: 4.1
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-4571.patch, LUCENE-4571.patch, LUCENE-4571.patch,
> LUCENE-4571.patch, LUCENE-4571.patch
>
>
> even minShouldMatch is supplied to DisjunctionSumScorer it enumerates whole
> disjunction, and verifies minShouldMatch condition [on every
> doc|https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/search/DisjunctionSumScorer.java#L70]:
> {code}
> public int nextDoc() throws IOException {
> assert doc != NO_MORE_DOCS;
> while(true) {
> while (subScorers[0].docID() == doc) {
> if (subScorers[0].nextDoc() != NO_MORE_DOCS) {
> heapAdjust(0);
> } else {
> heapRemoveRoot();
> if (numScorers < minimumNrMatchers) {
> return doc = NO_MORE_DOCS;
> }
> }
> }
> afterNext();
> if (nrMatchers >= minimumNrMatchers) {
> break;
> }
> }
>
> return doc;
> }
> {code}
> [~spo] proposes (as well as I get it) to pop nrMatchers-1 scorers from the
> heap first, and then push them back advancing behind that top doc. For me the
> question no.1 is there a performance test for minShouldMatch constrained
> disjunction.
--
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-4625) solr query parser should use multiplicative boosts and not apply phase slop to nested queries from a different qparser
[
https://issues.apache.org/jira/browse/SOLR-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609545#comment-13609545
]
Commit Tag Bot commented on SOLR-4625:
--
[trunk commit] Yonik Seeley
http://svn.apache.org/viewvc?view=revision&revision=1459537
SOLR-4625: fix boosts and phrase slops on sub parsers
> solr query parser should use multiplicative boosts and not apply phase slop
> to nested queries from a different qparser
> --
>
> Key: SOLR-4625
> URL: https://issues.apache.org/jira/browse/SOLR-4625
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Yonik Seeley
>Priority: Minor
> Fix For: 4.3, 5.0, 4.2.1
>
> Attachments: SOLR-4625.patch
>
>
> As reported by Michael Ryan,
> {code}
> _query_:"\"a b\"~2"~3 is parsed as "a b"~3
> {code}
> Additionally,
> {code}
> _query_:"x^2"^3 is parsed as x^3
> {code}
--
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] (LUCENE-4571) speedup disjunction with minShouldMatch
[
https://issues.apache.org/jira/browse/LUCENE-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609543#comment-13609543
]
Commit Tag Bot commented on LUCENE-4571:
[branch_4x commit] Robert Muir
http://svn.apache.org/viewvc?view=revision&revision=1459522
LUCENE-4571: improve minShouldMatch testing
> speedup disjunction with minShouldMatch
>
>
> Key: LUCENE-4571
> URL: https://issues.apache.org/jira/browse/LUCENE-4571
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: 4.1
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-4571.patch, LUCENE-4571.patch, LUCENE-4571.patch,
> LUCENE-4571.patch, LUCENE-4571.patch
>
>
> even minShouldMatch is supplied to DisjunctionSumScorer it enumerates whole
> disjunction, and verifies minShouldMatch condition [on every
> doc|https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/search/DisjunctionSumScorer.java#L70]:
> {code}
> public int nextDoc() throws IOException {
> assert doc != NO_MORE_DOCS;
> while(true) {
> while (subScorers[0].docID() == doc) {
> if (subScorers[0].nextDoc() != NO_MORE_DOCS) {
> heapAdjust(0);
> } else {
> heapRemoveRoot();
> if (numScorers < minimumNrMatchers) {
> return doc = NO_MORE_DOCS;
> }
> }
> }
> afterNext();
> if (nrMatchers >= minimumNrMatchers) {
> break;
> }
> }
>
> return doc;
> }
> {code}
> [~spo] proposes (as well as I get it) to pop nrMatchers-1 scorers from the
> heap first, and then push them back advancing behind that top doc. For me the
> question no.1 is there a performance test for minShouldMatch constrained
> disjunction.
--
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
Apache account created
Hi Shawn, FYI, ASF infrastructure just created an account for you and granted you membership to LDAP groups 'lucene' and 'committers' - the 'lucene' group allows you to commit to the Lucene and Solr websites, and to svn.apache.org/repos/asf/lucene/dev/. So you should now start checking out using https://... URLs instead of (read-only) http:// URLs - you won't be able to commit from http://... working copies. Please let us know if you run into trouble. Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4626) TestCoreContainer Fail: AlreadyClosedException: this IndexWriter is closed
[
https://issues.apache.org/jira/browse/SOLR-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609531#comment-13609531
]
Mark Miller commented on SOLR-4626:
---
{noformat}
[junit4:junit4] 2> 2447 T1093 oas.SolrTestCaseJ4.tearDown ###Ending testReload
[junit4:junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestCoreContainer -Dtests.method=testReload
-Dtests.seed=9CC00CFF005BBE3C -Dtests.slow=true -Dtests.locale=es_BO
-Dtests.timezone=America/Anchorage -Dtests.file.encoding=ISO-8859-1
[junit4:junit4] ERROR 0.66s J7 | TestCoreContainer.testReload <<<
[junit4:junit4]> Throwable #1:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught
exception in thread: Thread[id=1100, name=Thread-324, state=RUNNABLE,
group=TGRP-TestCoreContainer]
[junit4:junit4]>at
__randomizedtesting.SeedInfo.seed([9CC00CFF005BBE3C:5B3074FCCA18462E]:0)
[junit4:junit4]> Caused by: org.apache.solr.common.SolrException: Unable to
reload core: collection1
[junit4:junit4]>at
__randomizedtesting.SeedInfo.seed([9CC00CFF005BBE3C]:0)
[junit4:junit4]>at
org.apache.solr.core.CoreContainer.recordAndThrow(CoreContainer.java:1672)
[junit4:junit4]>at
org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1200)
[junit4:junit4]>at
org.apache.solr.core.TestCoreContainer$1TestThread.run(TestCoreContainer.java:90)
[junit4:junit4]> Caused by: org.apache.solr.common.SolrException: Error
opening new searcher
[junit4:junit4]>at
org.apache.solr.core.SolrCore.(SolrCore.java:823)
[junit4:junit4]>at
org.apache.solr.core.SolrCore.reload(SolrCore.java:408)
[junit4:junit4]>at
org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1189)
[junit4:junit4]>... 1 more
[junit4:junit4]> Caused by: org.apache.solr.common.SolrException: Error
opening new searcher
[junit4:junit4]>at
org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1432)
[junit4:junit4]>at
org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1544)
[junit4:junit4]>at
org.apache.solr.core.SolrCore.(SolrCore.java:798)
[junit4:junit4]>... 3 more
[junit4:junit4]> Caused by: org.apache.lucene.store.AlreadyClosedException:
this IndexWriter is closed
[junit4:junit4]>at
org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:583)
[junit4:junit4]>at
org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:597)
[junit4:junit4]>at
org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:331)
[junit4:junit4]>at
org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:110)
[junit4:junit4]>at
org.apache.solr.core.SolrCore$2.call(SolrCore.java:785)
[junit4:junit4]>at
org.apache.solr.core.SolrCore$2.call(SolrCore.java:782)
[junit4:junit4]>at
org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1403)
[junit4:junit4]>... 5 more
{noformat}
> TestCoreContainer Fail: AlreadyClosedException: this IndexWriter is closed
> --
>
> Key: SOLR-4626
> URL: https://issues.apache.org/jira/browse/SOLR-4626
> Project: Solr
> Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.3, 5.0, 4.2.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
[jira] [Created] (SOLR-4626) TestCoreContainer Fail: AlreadyClosedException: this IndexWriter is closed
Mark Miller created SOLR-4626: - Summary: TestCoreContainer Fail: AlreadyClosedException: this IndexWriter is closed Key: SOLR-4626 URL: https://issues.apache.org/jira/browse/SOLR-4626 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.3, 5.0, 4.2.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
[jira] [Commented] (SOLR-4563) RSS DIH-example not working
[ https://issues.apache.org/jira/browse/SOLR-4563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609519#comment-13609519 ] shenzhuxi commented on SOLR-4563: - Why this issue https://issues.apache.org/jira/browse/SOLR-2190 was closed? No one cares about the examples? > RSS DIH-example not working > --- > > Key: SOLR-4563 > URL: https://issues.apache.org/jira/browse/SOLR-4563 > Project: Solr > Issue Type: Bug >Affects Versions: 4.2 >Reporter: Jan Høydahl > Fix For: 4.3, 5.0 > > Attachments: SOLR-4563.patch > > > The xpath paths of /rss/item do not match the real world RSS feed which uses > /rss/channel/item -- 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] (LUCENE-4864) Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 only)
[ https://issues.apache.org/jira/browse/LUCENE-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609518#comment-13609518 ] Dawid Weiss commented on LUCENE-4864: - Hi Uwe. Michael is right -- we will need to override that default factory and mark those threads somehow because on non-windows systems the threadpool generated threads that just cannot be linked to their source. Now I recall this was the reason I was changing a lot of Solr's anonymous threadpools to something that could be identified. An alternative is to ignore all daemon threads. This is also an option. Although Michael is probably right that this property should be supported on all JVMs (it's a contract on a stdlibrary class) so there's nothing to worry about. > Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 > only) > --- > > Key: LUCENE-4864 > URL: https://issues.apache.org/jira/browse/LUCENE-4864 > Project: Lucene - Core > Issue Type: Improvement > Components: core/store >Affects Versions: 5.0 >Reporter: Michael Poindexter > Attachments: LUCENE-4864.patch, LUCENE-4864.patch > > > On LUCENE-4848 a new directory implementation was proposed that uses > AsyncFileChannel to make a sync-less directory implementation (only needed > for IndexInput). The problem on Windows is that positional reads are > impossible without overlapping (async) I/O, so FileChannel in the JDK has to > syncronize all reads, because they consist of an atomic seek and atomic read. > AsyncFSDirectoty would not have this issue, but has to take care of thread > management, because you need a separate thread to get notified when the read > is done. This involves overhead, but might still be better than the > synchronization. -- 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-4361) DIH request parameters with dots throws UnsupportedOperationException
[ https://issues.apache.org/jira/browse/SOLR-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609511#comment-13609511 ] James Dyer commented on SOLR-4361: -- If this is still a problem for you, by all means, reopen. Please include the line in your data-config.xml that has the variable that doesn't resolve and also the url you're using (or section from solrconfig.xml that has the variable in "defaults"). Based on TestVariableResolverEndToEnd, which does something very similar to what you describe, I would not expect this to still fail. > DIH request parameters with dots throws UnsupportedOperationException > - > > Key: SOLR-4361 > URL: https://issues.apache.org/jira/browse/SOLR-4361 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 4.1 >Reporter: James Dyer >Assignee: James Dyer >Priority: Minor > Fix For: 4.3, 5.0, 4.2.1 > > Attachments: SOLR-4361.patch > > > If the user puts placeholders for request parameters and these contain dots, > DIH fails. Current workaround is to either use no dots or use the 4.0 DIH > jar. -- 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-4361) DIH request parameters with dots throws UnsupportedOperationException
[ https://issues.apache.org/jira/browse/SOLR-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609493#comment-13609493 ] Chris Eldredge commented on SOLR-4361: -- Yes, upgrading from 4.0 to 4.2 breaks DIH for me. I'm using the URLDataSource with variables in the baseUrl, such as dataimport.request.server.prefix. The properties are all replaced with empty strings whereas in 4.0 they're correctly substituted. I'll test using variables that don't contain dots to make sure it's related to this issue. > DIH request parameters with dots throws UnsupportedOperationException > - > > Key: SOLR-4361 > URL: https://issues.apache.org/jira/browse/SOLR-4361 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 4.1 >Reporter: James Dyer >Assignee: James Dyer >Priority: Minor > Fix For: 4.3, 5.0, 4.2.1 > > Attachments: SOLR-4361.patch > > > If the user puts placeholders for request parameters and these contain dots, > DIH fails. Current workaround is to either use no dots or use the 4.0 DIH > jar. -- 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-4625) solr query parser should use multiplicative boosts and not apply phase slop to nested queries from a different qparser
[
https://issues.apache.org/jira/browse/SOLR-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-4625:
---
Attachment: SOLR-4625.patch
Here's a patch. I plan on committing shortly.
> solr query parser should use multiplicative boosts and not apply phase slop
> to nested queries from a different qparser
> --
>
> Key: SOLR-4625
> URL: https://issues.apache.org/jira/browse/SOLR-4625
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Yonik Seeley
>Priority: Minor
> Fix For: 4.3, 5.0, 4.2.1
>
> Attachments: SOLR-4625.patch
>
>
> As reported by Michael Ryan,
> {code}
> _query_:"\"a b\"~2"~3 is parsed as "a b"~3
> {code}
> Additionally,
> {code}
> _query_:"x^2"^3 is parsed as x^3
> {code}
--
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-4625) solr query parser should use multiplicative boosts and not apply phase slop to nested queries from a different qparser
Yonik Seeley created SOLR-4625:
--
Summary: solr query parser should use multiplicative boosts and
not apply phase slop to nested queries from a different qparser
Key: SOLR-4625
URL: https://issues.apache.org/jira/browse/SOLR-4625
Project: Solr
Issue Type: Bug
Affects Versions: 1.4
Reporter: Yonik Seeley
Priority: Minor
Fix For: 4.3, 5.0, 4.2.1
As reported by Michael Ryan,
{code}
_query_:"\"a b\"~2"~3 is parsed as "a b"~3
{code}
Additionally,
{code}
_query_:"x^2"^3 is parsed as x^3
{code}
--
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] (LUCENE-4571) speedup disjunction with minShouldMatch
[
https://issues.apache.org/jira/browse/LUCENE-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609460#comment-13609460
]
Robert Muir commented on LUCENE-4571:
-
OK: I committed a new test (TestMinShouldMatch2), it demonstrates the bug
this currently passes on trunk but fails with the patch.
you can also run it many times with ant test -Dtestcase=TestMinShouldMatch2
-Dtests.iters=100 and so on.
the test is not very thorough yet but its an improvement for now.
> speedup disjunction with minShouldMatch
>
>
> Key: LUCENE-4571
> URL: https://issues.apache.org/jira/browse/LUCENE-4571
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Affects Versions: 4.1
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-4571.patch, LUCENE-4571.patch, LUCENE-4571.patch,
> LUCENE-4571.patch, LUCENE-4571.patch
>
>
> even minShouldMatch is supplied to DisjunctionSumScorer it enumerates whole
> disjunction, and verifies minShouldMatch condition [on every
> doc|https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/search/DisjunctionSumScorer.java#L70]:
> {code}
> public int nextDoc() throws IOException {
> assert doc != NO_MORE_DOCS;
> while(true) {
> while (subScorers[0].docID() == doc) {
> if (subScorers[0].nextDoc() != NO_MORE_DOCS) {
> heapAdjust(0);
> } else {
> heapRemoveRoot();
> if (numScorers < minimumNrMatchers) {
> return doc = NO_MORE_DOCS;
> }
> }
> }
> afterNext();
> if (nrMatchers >= minimumNrMatchers) {
> break;
> }
> }
>
> return doc;
> }
> {code}
> [~spo] proposes (as well as I get it) to pop nrMatchers-1 scorers from the
> heap first, and then push them back advancing behind that top doc. For me the
> question no.1 is there a performance test for minShouldMatch constrained
> disjunction.
--
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] (LUCENE-4869) Fix the Within spatial predicate PrefixTree to remove false-positives
David Smiley created LUCENE-4869: Summary: Fix the Within spatial predicate PrefixTree to remove false-positives Key: LUCENE-4869 URL: https://issues.apache.org/jira/browse/LUCENE-4869 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: David Smiley LUCENE-4644 adds a useful initial capability to implement the "Within" predicate for a RecursivePrefixTree based field. But it will match false-positives for indexed shapes comprised of multiple disjoint parts. The solution to be worked out here is to index a point per disjoint part in such a way that it can be easily retrieved (e.g. DocValues) and then a post-process to WithinPrefixTreeFilter would remove false-positives. I didn't call this a 'bug' because this addresses a known temporary limitation, and Within is still useful despite this. -- 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-3706) Ship setup to log with log4j.
[ https://issues.apache.org/jira/browse/SOLR-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609454#comment-13609454 ] Mark Miller commented on SOLR-3706: --- bq. Do we want slf4j-api in the .war or nothing? I think nothing is OK (as you have it) I don't think so - if we do that, everyone has claimed you cannot easily change the logging impl without building a custom war. bq. Unrelated... the .war includes restlet stuff? When I poke around the code that is only used in tests. Is the restlet infrastructure part of solr core now? Yes, the schema read side rest api uses it - new in 4.2. > Ship setup to log with log4j. > - > > Key: SOLR-3706 > URL: https://issues.apache.org/jira/browse/SOLR-3706 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.3, 5.0 > > Attachments: SOLR-3706.patch, SOLR-3706-solr-log4j.patch, > SOLR-3706-solr-log4j.patch > > > Currently we default to java util logging and it's terrible in my opinion. > *It's simple built in logger is a 2 line logger. > *You have to jump through hoops to use your own custom formatter with jetty - > either putting your class in the start.jar or other pain in the butt > solutions. > *It can't roll files by date out of the box. > I'm sure there are more issues, but those are the ones annoying me now. We > should switch to log4j - it's much nicer and it's easy to get a nice single > line format and roll by date, etc. > If someone wants to use JUL they still can - but at least users could start > with something decent. -- 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-3706) Ship setup to log with log4j.
[ https://issues.apache.org/jira/browse/SOLR-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609446#comment-13609446 ] Ryan McKinley commented on SOLR-3706: - Do we want slf4j-api in the .war or nothing? I think nothing is OK (as you have it) Unrelated... the .war includes restlet stuff? When I poke around the code that is only used in tests. Is the restlet infrastructure part of solr core now? I'm testing maven stuff and will let you know if that looks OK > Ship setup to log with log4j. > - > > Key: SOLR-3706 > URL: https://issues.apache.org/jira/browse/SOLR-3706 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.3, 5.0 > > Attachments: SOLR-3706.patch, SOLR-3706-solr-log4j.patch, > SOLR-3706-solr-log4j.patch > > > Currently we default to java util logging and it's terrible in my opinion. > *It's simple built in logger is a 2 line logger. > *You have to jump through hoops to use your own custom formatter with jetty - > either putting your class in the start.jar or other pain in the butt > solutions. > *It can't roll files by date out of the box. > I'm sure there are more issues, but those are the ones annoying me now. We > should switch to log4j - it's much nicer and it's easy to get a nice single > line format and roll by date, etc. > If someone wants to use JUL they still can - but at least users could start > with something decent. -- 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] (LUCENE-4644) Implement spatial WITHIN query for RecursivePrefixTree
[ https://issues.apache.org/jira/browse/LUCENE-4644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609445#comment-13609445 ] David Smiley commented on LUCENE-4644: -- Ok so I'll perhaps commit this tomorrow or later if you want time to review the patch first. I think implementing the false-positive removal will introduce significantly more work to warrant a separate issue to track that. For example, SOLR-4329 needs to get addressed, and probably LUCENE-4698. My tentative CHANGES.txt entry will be (new feature): * LUCENE-4644: Added support for the "Within" spatial predicate for RecursivePrefixTreeStrategy. It is for matching non-point indexed shapes; if you only have points (1/doc) then "Intersects" is equivalent and faster. If an indexed shape is comprised of multiple disjoint parts, then this predicate might match false-positives; see LUCENE-. If before the next release this shortcoming is addressed then I'll remove that caveat. > Implement spatial WITHIN query for RecursivePrefixTree > -- > > Key: LUCENE-4644 > URL: https://issues.apache.org/jira/browse/LUCENE-4644 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/spatial >Reporter: David Smiley >Assignee: David Smiley > Attachments: > LUCENE-4644_Spatial_Within_predicate_for_RecursivePrefixTree.patch > > -- 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-3706) Ship setup to log with log4j.
[ https://issues.apache.org/jira/browse/SOLR-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609437#comment-13609437 ] Mark Miller commented on SOLR-3706: --- Hmm..looks like ant test fails in the solrj module are not picking up the logging config file in core. For the moment I think I can just put it in the solrj test-files dir as well. It may be better longer term to get a test-file dir for the test-framework module and have one copy there if that is possible. > Ship setup to log with log4j. > - > > Key: SOLR-3706 > URL: https://issues.apache.org/jira/browse/SOLR-3706 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.3, 5.0 > > Attachments: SOLR-3706.patch, SOLR-3706-solr-log4j.patch, > SOLR-3706-solr-log4j.patch > > > Currently we default to java util logging and it's terrible in my opinion. > *It's simple built in logger is a 2 line logger. > *You have to jump through hoops to use your own custom formatter with jetty - > either putting your class in the start.jar or other pain in the butt > solutions. > *It can't roll files by date out of the box. > I'm sure there are more issues, but those are the ones annoying me now. We > should switch to log4j - it's much nicer and it's easy to get a nice single > line format and roll by date, etc. > If someone wants to use JUL they still can - but at least users could start > with something decent. -- 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-4623) Add REST API methods to get all remaining schema information, and also to return the full live schema in json, xml, and schema.xml formats
[ https://issues.apache.org/jira/browse/SOLR-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609435#comment-13609435 ] Steve Rowe commented on SOLR-4623: -- bq. Also changes output path for copyFields and dynamicFields from "copyfields" and "dynamicfields" (all lowercase) to "copyFields" and "dynamicFields", respectively, to mirror all other REST API outputs, which use camel-case. I want to point out a design choice I've made with the REST API URLs: I followed what appears to me to be a pattern in Solr's URLs: all paths elements in lowercase, and query params either in camel-case or dots.separating.words formats. > Add REST API methods to get all remaining schema information, and also to > return the full live schema in json, xml, and schema.xml formats > -- > > Key: SOLR-4623 > URL: https://issues.apache.org/jira/browse/SOLR-4623 > Project: Solr > Issue Type: Sub-task > Components: Schema and Analysis >Affects Versions: 4.2 >Reporter: Steve Rowe >Assignee: Steve Rowe >Priority: Minor > Fix For: 4.3 > > Attachments: JSONResponseWriter.output.json, > SchemaXmlResponseWriter.output.xml, SOLR-4623.patch, > XMLResponseWriter.output.xml > > > Each remaining schema component (after field types, fields, dynamic fields, > copy fields were added by SOLR-4503) should be available from the schema REST > API: name, version, default query operator, similarity, default search field, > and unique key. > It should be possible to get the entire live schema back with a single > request, and schema.xml format should be one of the supported response > formats. -- 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-4361) DIH request parameters with dots throws UnsupportedOperationException
[ https://issues.apache.org/jira/browse/SOLR-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609432#comment-13609432 ] James Dyer commented on SOLR-4361: -- Chris, Do you have a real-world problem that is still broken, or is this just a problem with modifying TestURLDataSource? This issue is tested in TestVariableResolverEndToEnd. The solrconfig.xml file contains a default parameter "dots.in.hsqldb.driver" with the driver name. The test subsequently references . Prior to fixing VariableResolver, this test would fail because the driver name would not resolve. With this fix, the test passes. The difference is that the "dataimporter.request" namespaces are (in reality) added by DocBuilder#getVariableResolver by creating a map for the "dataimporter" namespace and then a child map for the "request" namespace. With the fix here, VariableResolver is still requiring each node in the Variable tree to be added individually, rather than taking the shortcut you used in your modified version of TestURLDataSource. However, it is more forgiving with variable names containing dots: if it cannot walk the tree to find the rightmost name, then it goes as far as it can and then assumes the rest is a name with embedded dots in it. > DIH request parameters with dots throws UnsupportedOperationException > - > > Key: SOLR-4361 > URL: https://issues.apache.org/jira/browse/SOLR-4361 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 4.1 >Reporter: James Dyer >Assignee: James Dyer >Priority: Minor > Fix For: 4.3, 5.0, 4.2.1 > > Attachments: SOLR-4361.patch > > > If the user puts placeholders for request parameters and these contain dots, > DIH fails. Current workaround is to either use no dots or use the 4.0 DIH > jar. -- 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-4623) Add REST API methods to get all remaining schema information, and also to return the full live schema in json, xml, and schema.xml formats
[ https://issues.apache.org/jira/browse/SOLR-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe updated SOLR-4623: - Attachment: SchemaXmlResponseWriter.output.xml XMLResponseWriter.output.xml JSONResponseWriter.output.json SOLR-4623.patch Patch. The full schema is available via the "/schema" path, e.g. [http://localhost:8983/solr/collection1/schema]. "?wt=json" and "?wt=xml" produce the expected output formats. SchemaXmlResponseWriter is added to provide output in schema.xml format, available via "?wt=schema.xml". Samples attached. Also moves schema REST API methods from package org.apache.solr.rest to org.apache.solr.rest.schema, and renames base functionality REST API classes to remove the current schema focus, to prepare for other non-schema REST APIs. Also changes output path for copyFields and dynamicFields from "copyfields" and "dynamicfields" (all lowercase) to "copyFields" and "dynamicFields", respectively, to mirror all other REST API outputs, which use camel-case. I think this is ready to go. > Add REST API methods to get all remaining schema information, and also to > return the full live schema in json, xml, and schema.xml formats > -- > > Key: SOLR-4623 > URL: https://issues.apache.org/jira/browse/SOLR-4623 > Project: Solr > Issue Type: Sub-task > Components: Schema and Analysis >Affects Versions: 4.2 >Reporter: Steve Rowe >Assignee: Steve Rowe >Priority: Minor > Fix For: 4.3 > > Attachments: JSONResponseWriter.output.json, > SchemaXmlResponseWriter.output.xml, SOLR-4623.patch, > XMLResponseWriter.output.xml > > > Each remaining schema component (after field types, fields, dynamic fields, > copy fields were added by SOLR-4503) should be available from the schema REST > API: name, version, default query operator, similarity, default search field, > and unique key. > It should be possible to get the entire live schema back with a single > request, and schema.xml format should be one of the supported response > formats. -- 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-4624) CachingDirectoryFactory does not need to support forceNew any longer and it may be causing a missing close directory bug.
[ https://issues.apache.org/jira/browse/SOLR-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609420#comment-13609420 ] Mark Miller commented on SOLR-4624: --- I'm probably going to put a 'nueter forceNew' back port in 4.2.1 that doesn't change any apis, just doesn't do force a new directory. With the other changes in 4.2.1, this is fine to do. > CachingDirectoryFactory does not need to support forceNew any longer and it > may be causing a missing close directory bug. > - > > Key: SOLR-4624 > URL: https://issues.apache.org/jira/browse/SOLR-4624 > Project: Solr > Issue Type: Task >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.3, 5.0 > > > Our forceNew uses were essentially hacks that have been replaced with correct > solutions. We should remove it. -- 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-4624) CachingDirectoryFactory does not need to support forceNew any longer and it may be causing a missing close directory bug.
Mark Miller created SOLR-4624: - Summary: CachingDirectoryFactory does not need to support forceNew any longer and it may be causing a missing close directory bug. Key: SOLR-4624 URL: https://issues.apache.org/jira/browse/SOLR-4624 Project: Solr Issue Type: Task Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.3, 5.0 Our forceNew uses were essentially hacks that have been replaced with correct solutions. We should remove it. -- 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-4618) Integrate LucidWorks' Solr Reference Guide with Solr documentation
[ https://issues.apache.org/jira/browse/SOLR-4618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609410#comment-13609410 ] Alexandre Rafalovitch commented on SOLR-4618: - Interestingly, GitHub pages (where GitHub projects store documentation) are GitHub repositories themselves. Though I don't think one could do a Pull request to it. But it could be a thing to consider with Wiki pages stored in GitHub as a standalone project and then generated into static and fast content using something like MiddleMan. Then, the proposed changes become Pull Requests. GitHub very recently added some non-techie interface for doing easy changes+Pull requests. Comments could be a dynamic Javascript add-on then. And Confluence export is XML, easy enough to reformat that into anything, including a set of files. > Integrate LucidWorks' Solr Reference Guide with Solr documentation > -- > > Key: SOLR-4618 > URL: https://issues.apache.org/jira/browse/SOLR-4618 > Project: Solr > Issue Type: Improvement > Components: documentation >Affects Versions: 4.1 >Reporter: Cassandra Targett > Attachments: NewSolrStyle.css, SolrRefGuide4.1-ASF.zip > > > LucidWorks would like to donate the "Apache Solr Reference Guide", maintained > by LucidWorks tech writers, to the Solr community. It was first produced in > 2009 as a download-only PDF for Solr 1.4, but since 2011 it has been online > at http://docs.lucidworks.com/display/solr/ and updated for Solr 3.x releases > and for Solr 4.0 and 4.1. > I've prepared an XML export from our Confluence installation, which can be > easily imported into the Apache Confluence installation by someone with > system admin rights. The doc has not yet been updated for 4.2, so it covers > Solr 4.1 so far. I'll add some additional technical notes about the export > itself in a comment. > Since we use Confluence at LucidWorks, I can also offer assistance getting > Confluence set up, importing this package into it, or any other help needed > for the community to start using this. -- 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-4361) DIH request parameters with dots throws UnsupportedOperationException
[
https://issues.apache.org/jira/browse/SOLR-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609404#comment-13609404
]
Chris Eldredge commented on SOLR-4361:
--
Request to reopen this issue. Testing on lucene_solr_4_2 r1459428,
TestURLDataSource is still broken when changing "baseurl" to "base.url" and
"${dataimporter.request.baseurl}" to "${dataimporter.request.base.url}".
> DIH request parameters with dots throws UnsupportedOperationException
> -
>
> Key: SOLR-4361
> URL: https://issues.apache.org/jira/browse/SOLR-4361
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 4.1
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Fix For: 4.3, 5.0, 4.2.1
>
> Attachments: SOLR-4361.patch
>
>
> If the user puts placeholders for request parameters and these contain dots,
> DIH fails. Current workaround is to either use no dots or use the 4.0 DIH
> jar.
--
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-3706) Ship setup to log with log4j.
[ https://issues.apache.org/jira/browse/SOLR-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609398#comment-13609398 ] Mark Miller commented on SOLR-3706: --- Just some general sanity review would be good. I tried running tests in eclipse as well as making sure test fails with ant test still logged. Someone might have comments on the logging format, I got it from the wiki or something. I also tested run-example and it logs. I updated the README to mention you might want to turn off the console logging and that we use log4j by default. If someone can review, I'll commit it. > Ship setup to log with log4j. > - > > Key: SOLR-3706 > URL: https://issues.apache.org/jira/browse/SOLR-3706 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.3, 5.0 > > Attachments: SOLR-3706.patch, SOLR-3706-solr-log4j.patch, > SOLR-3706-solr-log4j.patch > > > Currently we default to java util logging and it's terrible in my opinion. > *It's simple built in logger is a 2 line logger. > *You have to jump through hoops to use your own custom formatter with jetty - > either putting your class in the start.jar or other pain in the butt > solutions. > *It can't roll files by date out of the box. > I'm sure there are more issues, but those are the ones annoying me now. We > should switch to log4j - it's much nicer and it's easy to get a nice single > line format and roll by date, etc. > If someone wants to use JUL they still can - but at least users could start > with something decent. -- 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] (LUCENE-4644) Implement spatial WITHIN query for RecursivePrefixTree
[ https://issues.apache.org/jira/browse/LUCENE-4644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609390#comment-13609390 ] Ryan McKinley commented on LUCENE-4644: --- bq. Within predicate will sometimes match false-positives in cases where the indexed shape for a document is really multi* shape This is a totally fine caveat (false negatives are harder) but false positives can always be refined with brute force > Implement spatial WITHIN query for RecursivePrefixTree > -- > > Key: LUCENE-4644 > URL: https://issues.apache.org/jira/browse/LUCENE-4644 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/spatial >Reporter: David Smiley >Assignee: David Smiley > Attachments: > LUCENE-4644_Spatial_Within_predicate_for_RecursivePrefixTree.patch > > -- 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-4623) Add REST API methods to get all remaining schema information, and also to return the full live schema in json, xml, and schema.xml formats
Steve Rowe created SOLR-4623: Summary: Add REST API methods to get all remaining schema information, and also to return the full live schema in json, xml, and schema.xml formats Key: SOLR-4623 URL: https://issues.apache.org/jira/browse/SOLR-4623 Project: Solr Issue Type: Sub-task Components: Schema and Analysis Affects Versions: 4.2 Reporter: Steve Rowe Assignee: Steve Rowe Priority: Minor Fix For: 4.3 Each remaining schema component (after field types, fields, dynamic fields, copy fields were added by SOLR-4503) should be available from the schema REST API: name, version, default query operator, similarity, default search field, and unique key. It should be possible to get the entire live schema back with a single request, and schema.xml format should be one of the supported response formats. -- 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-3706) Ship setup to log with log4j.
[ https://issues.apache.org/jira/browse/SOLR-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609386#comment-13609386 ] Ryan McKinley commented on SOLR-3706: - Mark -- anything you want me to look at? What are the things that need done before we can commit? (I think SolrLogFormatter should come as a follow on issue) > Ship setup to log with log4j. > - > > Key: SOLR-3706 > URL: https://issues.apache.org/jira/browse/SOLR-3706 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.3, 5.0 > > Attachments: SOLR-3706.patch, SOLR-3706-solr-log4j.patch, > SOLR-3706-solr-log4j.patch > > > Currently we default to java util logging and it's terrible in my opinion. > *It's simple built in logger is a 2 line logger. > *You have to jump through hoops to use your own custom formatter with jetty - > either putting your class in the start.jar or other pain in the butt > solutions. > *It can't roll files by date out of the box. > I'm sure there are more issues, but those are the ones annoying me now. We > should switch to log4j - it's much nicer and it's easy to get a nice single > line format and roll by date, etc. > If someone wants to use JUL they still can - but at least users could start > with something decent. -- 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] (LUCENE-4644) Implement spatial WITHIN query for RecursivePrefixTree
[ https://issues.apache.org/jira/browse/LUCENE-4644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-4644: - Attachment: LUCENE-4644_Spatial_Within_predicate_for_RecursivePrefixTree.patch Attached is a patch that implements a spatial "Within" predicate for RecursivePrefixTree. Summary of changes in patch, which includes some unrelated things: * Added SpatialPrefixTree.getDistanceForLevel(level):double -- used by the Within filter to help it 'buffer' the query shape slightly * Migrated AbstractPrefixTreeFilter to use FixedBitSet instead of OpenBitSet, because FBS is preferred in Lucene (paraphrasing Uwe) * Moved some point vs rect interpretation of a cell from AbstractVisitingPrefixTreeFilter to subclass IntersectsPrefixTreeFilter since that logic is not applicable to Within The test is randomized and thus fairly thorough, notwithstanding that it doesn't test a geospatial context. I'd like to add that but in order to do so, gridSnap would ideally use some utility classes/logic in Spatial4j trunk that isn't here. So I'll add that in the future. The big thing missing here is that this Within predicate will sometimes match false-positives in cases where the indexed shape for a document is really multi* shape -- i.e. is composed of multiple disjoint parts. I'd like to solve that separately using some sort of indexed field of center points of each disjoint part of indexed shapes. Maybe as a separate issue? But it would be nice to get this committed now, notwithstanding this interim limitation. > Implement spatial WITHIN query for RecursivePrefixTree > -- > > Key: LUCENE-4644 > URL: https://issues.apache.org/jira/browse/LUCENE-4644 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/spatial >Reporter: David Smiley >Assignee: David Smiley > Attachments: > LUCENE-4644_Spatial_Within_predicate_for_RecursivePrefixTree.patch > > -- 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-3706) Ship setup to log with log4j.
[ https://issues.apache.org/jira/browse/SOLR-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3706: -- Attachment: SOLR-3706.patch This builds on Ryan's patch. > Ship setup to log with log4j. > - > > Key: SOLR-3706 > URL: https://issues.apache.org/jira/browse/SOLR-3706 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.3, 5.0 > > Attachments: SOLR-3706.patch, SOLR-3706-solr-log4j.patch, > SOLR-3706-solr-log4j.patch > > > Currently we default to java util logging and it's terrible in my opinion. > *It's simple built in logger is a 2 line logger. > *You have to jump through hoops to use your own custom formatter with jetty - > either putting your class in the start.jar or other pain in the butt > solutions. > *It can't roll files by date out of the box. > I'm sure there are more issues, but those are the ones annoying me now. We > should switch to log4j - it's much nicer and it's easy to get a nice single > line format and roll by date, etc. > If someone wants to use JUL they still can - but at least users could start > with something decent. -- 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-3583) Percentiles for facets, pivot facets, and distributed pivot facets
[ https://issues.apache.org/jira/browse/SOLR-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Muldowney updated SOLR-3583: --- Attachment: SOLR-3583.patch Supports the recently updated 2894 patch > Percentiles for facets, pivot facets, and distributed pivot facets > -- > > Key: SOLR-3583 > URL: https://issues.apache.org/jira/browse/SOLR-3583 > Project: Solr > Issue Type: Improvement >Reporter: Chris Russell >Priority: Minor > Labels: newbie, patch > Fix For: 4.3 > > Attachments: SOLR-3583.patch, SOLR-3583.patch, SOLR-3583.patch, > SOLR-3583.patch > > > Built on top of SOLR-2894, this patch adds percentiles and averages to > facets, pivot facets, and distributed pivot facets by making use of range > facet internals. -- 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-3706) Ship setup to log with log4j.
[ https://issues.apache.org/jira/browse/SOLR-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609365#comment-13609365 ] Ryan McKinley commented on SOLR-3706: - bq. I'm going to say lets get log4j fully integrated and working well +1 log4j is common and the infrastructure changes we need to make that work are the same needed for logback or log4j2. Once we have things working, converting the SolrLogFormatter to Log4j would be great. > Ship setup to log with log4j. > - > > Key: SOLR-3706 > URL: https://issues.apache.org/jira/browse/SOLR-3706 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.3, 5.0 > > Attachments: SOLR-3706-solr-log4j.patch, SOLR-3706-solr-log4j.patch > > > Currently we default to java util logging and it's terrible in my opinion. > *It's simple built in logger is a 2 line logger. > *You have to jump through hoops to use your own custom formatter with jetty - > either putting your class in the start.jar or other pain in the butt > solutions. > *It can't roll files by date out of the box. > I'm sure there are more issues, but those are the ones annoying me now. We > should switch to log4j - it's much nicer and it's easy to get a nice single > line format and roll by date, etc. > If someone wants to use JUL they still can - but at least users could start > with something decent. -- 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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Muldowney updated SOLR-2894: --- Attachment: SOLR-2894.patch > Implement distributed pivot faceting > > > Key: SOLR-2894 > URL: https://issues.apache.org/jira/browse/SOLR-2894 > Project: Solr > Issue Type: Improvement >Reporter: Erik Hatcher > Fix For: 4.3 > > Attachments: SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, > SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, > SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, > SOLR-2894-reworked.patch > > > Following up on SOLR-792, pivot faceting currently only supports > undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Muldowney updated SOLR-2894: --- Attachment: (was: 0001-Pivot-Faceting-and-refinement.patch) > Implement distributed pivot faceting > > > Key: SOLR-2894 > URL: https://issues.apache.org/jira/browse/SOLR-2894 > Project: Solr > Issue Type: Improvement >Reporter: Erik Hatcher > Fix For: 4.3 > > Attachments: SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, > SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, > SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, > SOLR-2894-reworked.patch > > > Following up on SOLR-792, pivot faceting currently only supports > undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-2522) Change max() and min() to work on multiValued fields
[ https://issues.apache.org/jira/browse/SOLR-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609364#comment-13609364 ] Chris Emerson commented on SOLR-2522: - This would be incredibly helpful! Voting up. As a side note, I actually tried for a while to do this as it wasn't clear to me from the documentation on min() that it couldn't be done. As it stands I'm having to do sorting, and therefore pagination, on the client side which is a real drag, and necessitates bringing back the entire result set every time a new page is required. > Change max() and min() to work on multiValued fields > - > > Key: SOLR-2522 > URL: https://issues.apache.org/jira/browse/SOLR-2522 > Project: Solr > Issue Type: Improvement >Reporter: Bill Bell > > Switch max() and min() functions to work on multiValued fields so we can > do sort=min(fieldname) asc and the sort would work on multiValued fields... -- 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-4618) Integrate LucidWorks' Solr Reference Guide with Solr documentation
[ https://issues.apache.org/jira/browse/SOLR-4618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609337#comment-13609337 ] Per Steffensen commented on SOLR-4618: -- Have anyone considered storing doc in SVN alongside the code. This enables doc to follow code through branches, merges etc. Whenever you make an official release the corresponding doc can be made available online. Then you will have one doc site per official release. > Integrate LucidWorks' Solr Reference Guide with Solr documentation > -- > > Key: SOLR-4618 > URL: https://issues.apache.org/jira/browse/SOLR-4618 > Project: Solr > Issue Type: Improvement > Components: documentation >Affects Versions: 4.1 >Reporter: Cassandra Targett > Attachments: NewSolrStyle.css, SolrRefGuide4.1-ASF.zip > > > LucidWorks would like to donate the "Apache Solr Reference Guide", maintained > by LucidWorks tech writers, to the Solr community. It was first produced in > 2009 as a download-only PDF for Solr 1.4, but since 2011 it has been online > at http://docs.lucidworks.com/display/solr/ and updated for Solr 3.x releases > and for Solr 4.0 and 4.1. > I've prepared an XML export from our Confluence installation, which can be > easily imported into the Apache Confluence installation by someone with > system admin rights. The doc has not yet been updated for 4.2, so it covers > Solr 4.1 so far. I'll add some additional technical notes about the export > itself in a comment. > Since we use Confluence at LucidWorks, I can also offer assistance getting > Confluence set up, importing this package into it, or any other help needed > for the community to start using this. -- 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] (LUCENE-4864) Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 only)
[ https://issues.apache.org/jira/browse/LUCENE-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-4864: -- Attachment: LUCENE-4864.patch This patch also registers the new directory in LuceneTestCase to be randomly used. > Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 > only) > --- > > Key: LUCENE-4864 > URL: https://issues.apache.org/jira/browse/LUCENE-4864 > Project: Lucene - Core > Issue Type: Improvement > Components: core/store >Affects Versions: 5.0 >Reporter: Michael Poindexter > Attachments: LUCENE-4864.patch, LUCENE-4864.patch > > > On LUCENE-4848 a new directory implementation was proposed that uses > AsyncFileChannel to make a sync-less directory implementation (only needed > for IndexInput). The problem on Windows is that positional reads are > impossible without overlapping (async) I/O, so FileChannel in the JDK has to > syncronize all reads, because they consist of an atomic seek and atomic read. > AsyncFSDirectoty would not have this issue, but has to take care of thread > management, because you need a separate thread to get notified when the read > is done. This involves overhead, but might still be better than the > synchronization. -- 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] (LUCENE-4864) Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 only)
[ https://issues.apache.org/jira/browse/LUCENE-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-4864: -- Attachment: LUCENE-4864.patch I took the latest patch by Dawid Weiss from LUCENE-4848: - Removed the IndexOutput - Kept the AsyncFSIndexInput - Kept the QuickThreadsFilter All tests pass at least on Windows. > Add AsyncFSDirectory to work around Windows issues with NIOFS (Lucene 5.0 > only) > --- > > Key: LUCENE-4864 > URL: https://issues.apache.org/jira/browse/LUCENE-4864 > Project: Lucene - Core > Issue Type: Improvement > Components: core/store >Affects Versions: 5.0 >Reporter: Michael Poindexter > Attachments: LUCENE-4864.patch > > > On LUCENE-4848 a new directory implementation was proposed that uses > AsyncFileChannel to make a sync-less directory implementation (only needed > for IndexInput). The problem on Windows is that positional reads are > impossible without overlapping (async) I/O, so FileChannel in the JDK has to > syncronize all reads, because they consist of an atomic seek and atomic read. > AsyncFSDirectoty would not have this issue, but has to take care of thread > management, because you need a separate thread to get notified when the read > is done. This involves overhead, but might still be better than the > synchronization. -- 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-3755) shard splitting
[ https://issues.apache.org/jira/browse/SOLR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-3755: Attachment: SOLR-3755.patch Changes: # Fixed off-by-one mistake in replica creation # Commit before split # Better sub-shard node addition logic using shard ranges. Defensive checks in DUPF are modified to allow sub-shard replication. A new param distrib.from.shard is added to forwarded requests if node list contains sub-shard leaders. # Modified ShardSplitTest to index docs constantly (to check sub-shard replication). The test fails currently because the sub-shards now have more docs than they should have. I'm investigating this. Patch is created on top of trunk r1459441 via git. > shard splitting > --- > > Key: SOLR-3755 > URL: https://issues.apache.org/jira/browse/SOLR-3755 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Yonik Seeley > Attachments: SOLR-3755-combined.patch, > SOLR-3755-combinedWithReplication.patch, SOLR-3755-CoreAdmin.patch, > SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, > SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, > SOLR-3755-testSplitter.patch, SOLR-3755-testSplitter.patch > > > We can currently easily add replicas to handle increases in query volume, but > we should also add a way to add additional shards dynamically by splitting > existing shards. -- 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-3706) Ship setup to log with log4j.
[ https://issues.apache.org/jira/browse/SOLR-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609294#comment-13609294 ] Mark Miller commented on SOLR-3706: --- One thing that we would lose in tests with the current approach is [~yo...@apache.org]'s SolrLogFormatter. We would probably want to re-implement it. I'd much prefer that to trying to straddle different logging impls for example and tests. I think devs should see the logging users will see. And did I mention the single line logging? > Ship setup to log with log4j. > - > > Key: SOLR-3706 > URL: https://issues.apache.org/jira/browse/SOLR-3706 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.3, 5.0 > > Attachments: SOLR-3706-solr-log4j.patch, SOLR-3706-solr-log4j.patch > > > Currently we default to java util logging and it's terrible in my opinion. > *It's simple built in logger is a 2 line logger. > *You have to jump through hoops to use your own custom formatter with jetty - > either putting your class in the start.jar or other pain in the butt > solutions. > *It can't roll files by date out of the box. > I'm sure there are more issues, but those are the ones annoying me now. We > should switch to log4j - it's much nicer and it's easy to get a nice single > line format and roll by date, etc. > If someone wants to use JUL they still can - but at least users could start > with something decent. -- 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-3706) Ship setup to log with log4j.
[ https://issues.apache.org/jira/browse/SOLR-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609287#comment-13609287 ] Mark Miller commented on SOLR-3706: --- I've got this mostly working, though there are still a few little chads to work out. One line logging...it's beautiful :) I'm going to say lets get log4j fully integrated and working well - I think most of us know it best and it's already setup to work with the admin UI. If someone that knows logback can then use this as a starting base to switch to logback (should be much easier to build off this), that would be fine, else we can consider it later, or simply move to log4j2 later. Someone has said it offers the same benefits as logback. > Ship setup to log with log4j. > - > > Key: SOLR-3706 > URL: https://issues.apache.org/jira/browse/SOLR-3706 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.3, 5.0 > > Attachments: SOLR-3706-solr-log4j.patch, SOLR-3706-solr-log4j.patch > > > Currently we default to java util logging and it's terrible in my opinion. > *It's simple built in logger is a 2 line logger. > *You have to jump through hoops to use your own custom formatter with jetty - > either putting your class in the start.jar or other pain in the butt > solutions. > *It can't roll files by date out of the box. > I'm sure there are more issues, but those are the ones annoying me now. We > should switch to log4j - it's much nicer and it's easy to get a nice single > line format and roll by date, etc. > If someone wants to use JUL they still can - but at least users could start > with something decent. -- 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-1913) QParserPlugin plugin for Search Results Filtering Based on Bitwise Operations on Integer Fields
[
https://issues.apache.org/jira/browse/SOLR-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Israel Ekpo updated SOLR-1913:
--
Description:
BitwiseQueryParserPlugin is a org.apache.solr.search.QParserPlugin that allows
users to filter the documents returned from a query
by performing bitwise operations between a particular integer field in the index
and the specified value.
This Solr plugin is based on the BitwiseFilter in LUCENE-2460
See https://issues.apache.org/jira/browse/LUCENE-2460 for more details
This is the syntax for searching in Solr:
http://localhost:8983/path/to/solr/select/?q={!bitwise field=fieldname
op=OPERATION_NAME source=sourcevalue negate=boolean}remainder of query
Example :
http://localhost:8983/solr/bitwise/select/?q={!bitwise field=user_permissions
op=AND source=3 negate=true}state:FL
The negate parameter is optional
The field parameter is the name of the integer field
The op parameter is the name of the operation; one of {AND, OR, XOR}
The source parameter is the specified integer value
The negate parameter is a boolean indicating whether or not to negate the
results of the bitwise operation
To test out this plugin, simply copy the jar file containing the plugin classes
into your $SOLR_HOME/lib directory and then
add the following to your solrconfig.xml file after the dismax request handler:
Restart your servlet container.
was:
BitwiseQueryParserPlugin is a org.apache.solr.search.QParserPlugin that allows
users to filter the documents returned from a query
by performing bitwise operations between a particular integer field in the index
and the specified value.
This Solr plugin is based on the BitwiseFilter in LUCENE-2460
See https://issues.apache.org/jira/browse/LUCENE-2460 for more details
This is the syntax for searching in Solr:
http://localhost:8983/path/to/solr/select/?q={!bitwise field=fieldname
op=OPERATION_NAME source=sourcevalue negate=boolean}remainder of query
Example :
http://localhost:8983/solr/bitwise/select/?q={!bitwise field=user_permissions
op=AND source=3 negate=true}state:FL
The negate parameter is optional
The field parameter is the name of the integer field
The op parameter is the name of the operation; one of {AND, OR, XOR}
The source parameter is the specified integer value
The negate parameter is a boolean indicating whether or not to negate the
results of the bitwise operation
To test out this plugin, simply copy the jar file containing the plugin classes
into your $SOLR_HOME/lib directory and then
add the following to your solrconfig.xml file after the dismax request handler:
Restart your servlet container.
> QParserPlugin plugin for Search Results Filtering Based on Bitwise Operations
> on Integer Fields
> ---
>
> Key: SOLR-1913
> URL: https://issues.apache.org/jira/browse/SOLR-1913
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Israel Ekpo
> Fix For: 4.3
>
> Attachments: bitwise_filter_plugin.jar, SOLR-1913.bitwise.tar.gz
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> BitwiseQueryParserPlugin is a org.apache.solr.search.QParserPlugin that
> allows
> users to filter the documents returned from a query
> by performing bitwise operations between a particular integer field in the
> index
> and the specified value.
> This Solr plugin is based on the BitwiseFilter in LUCENE-2460
> See https://issues.apache.org/jira/browse/LUCENE-2460 for more details
> This is the syntax for searching in Solr:
> http://localhost:8983/path/to/solr/select/?q={!bitwise field=fieldname
> op=OPERATION_NAME source=sourcevalue negate=boolean}remainder of query
> Example :
> http://localhost:8983/solr/bitwise/select/?q={!bitwise field=user_permissions
> op=AND source=3 negate=true}state:FL
> The negate parameter is optional
> The field parameter is the name of the integer field
> The op parameter is the name of the operation; one of {AND, OR, XOR}
> The source parameter is the specified integer value
> The negate parameter is a boolean indicating whether or not to negate the
> results of the bitwise operation
> To test out this plugin, simply copy the jar file containing the plugin
> classes into your $SOLR_HOME/lib directory and then
> add the following to your solrconfig.xml file after the dismax request
> handler:
> class="org.apache.solr.bitwise.BitwiseQueryParserPlugin" basedOn="dismax" />
> Restart your servlet container.
--
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.a
[jira] [Commented] (SOLR-1913) QParserPlugin plugin for Search Results Filtering Based on Bitwise Operations on Integer Fields
[
https://issues.apache.org/jira/browse/SOLR-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609283#comment-13609283
]
Israel Ekpo commented on SOLR-1913:
---
Hi Guys,
I will take a look at the suggestions that Yonik made and try to see how I can
fix it.
> QParserPlugin plugin for Search Results Filtering Based on Bitwise Operations
> on Integer Fields
> ---
>
> Key: SOLR-1913
> URL: https://issues.apache.org/jira/browse/SOLR-1913
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Israel Ekpo
> Fix For: 4.3
>
> Attachments: bitwise_filter_plugin.jar, SOLR-1913.bitwise.tar.gz
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> BitwiseQueryParserPlugin is a org.apache.solr.search.QParserPlugin that
> allows
> users to filter the documents returned from a query
> by performing bitwise operations between a particular integer field in the
> index
> and the specified value.
> This Solr plugin is based on the BitwiseFilter in LUCENE-2460
> See https://issues.apache.org/jira/browse/LUCENE-2460 for more details
> This is the syntax for searching in Solr:
> http://localhost:8983/path/to/solr/select/?q={!bitwise field=fieldname
> op=OPERATION_NAME source=sourcevalue negate=boolean}remainder of query
> Example :
> http://localhost:8983/solr/bitwise/select/?q={!bitwise field=user_permissions
> op=AND source=3 negate=true}state:FL
> The negate parameter is optional
> The field parameter is the name of the integer field
> The op parameter is the name of the operation; one of {AND, OR, XOR}
> The source parameter is the specified integer value
> The negate parameter is a boolean indicating whether or not to negate the
> results of the bitwise operation
> To test out this plugin, simply copy the jar file containing the plugin
> classes into your $SOLR_HOME/lib directory and then
> add the following to your solrconfig.xml file after the dismax request
> handler:
> class="org.apache.solr.bitwise.BitwiseQueryParserPlugin" basedOn="dismax" />
> Restart your servlet container.
--
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] (LUCENE-4848) Fix Directory implementations to use NIO2 APIs
[ https://issues.apache.org/jira/browse/LUCENE-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609282#comment-13609282 ] Commit Tag Bot commented on LUCENE-4848: [trunk commit] Uwe Schindler http://svn.apache.org/viewvc?view=revision&revision=1459437 LUCENE-4848: Use Java 7 NIO2-FileChannel instead of RandomAccessFile for NIOFSDirectory and MMapDirectory > Fix Directory implementations to use NIO2 APIs > -- > > Key: LUCENE-4848 > URL: https://issues.apache.org/jira/browse/LUCENE-4848 > Project: Lucene - Core > Issue Type: Task >Affects Versions: 5.0 >Reporter: Michael Poindexter >Assignee: Uwe Schindler >Priority: Minor > Fix For: 5.0 > > Attachments: jdk7directory.zip, LUCENE-4848-MMapDirectory.patch, > LUCENE-4848.patch, LUCENE-4848.patch, LUCENE-4848.patch, LUCENE-4848.patch, > LUCENE-4848.patch, LUCENE-4848.patch, LUCENE-4848.patch, LUCENE-4848.patch, > LUCENE-4848.patch.txt > > > I have implemented 3 Directory subclasses using NIO2 API's (available on > JDK7). These may be suitable for inclusion in a Lucene contrib module. > See the mailing list at http://lucene.markmail.org/thread/lrv7miivzmjm3ml5 > for more details about this code and the advantages it provides. > The code is attached as a zip to this issue. I'll be happy to make any > changes requested. I've included some minimal smoke tests, but any help in > how to use the normal Lucene tests to perform more thorough testing would be > appreciated. -- 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] (LUCENE-4848) Fix Directory implementations to use NIO2 APIs
[ https://issues.apache.org/jira/browse/LUCENE-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-4848. --- Resolution: Fixed Thanks Michael! Let's move on to AsyncFSDirectory > Fix Directory implementations to use NIO2 APIs > -- > > Key: LUCENE-4848 > URL: https://issues.apache.org/jira/browse/LUCENE-4848 > Project: Lucene - Core > Issue Type: Task >Affects Versions: 5.0 >Reporter: Michael Poindexter >Assignee: Uwe Schindler >Priority: Minor > Fix For: 5.0 > > Attachments: jdk7directory.zip, LUCENE-4848-MMapDirectory.patch, > LUCENE-4848.patch, LUCENE-4848.patch, LUCENE-4848.patch, LUCENE-4848.patch, > LUCENE-4848.patch, LUCENE-4848.patch, LUCENE-4848.patch, LUCENE-4848.patch, > LUCENE-4848.patch.txt > > > I have implemented 3 Directory subclasses using NIO2 API's (available on > JDK7). These may be suitable for inclusion in a Lucene contrib module. > See the mailing list at http://lucene.markmail.org/thread/lrv7miivzmjm3ml5 > for more details about this code and the advantages it provides. > The code is attached as a zip to this issue. I'll be happy to make any > changes requested. I've included some minimal smoke tests, but any help in > how to use the normal Lucene tests to perform more thorough testing would be > appreciated. -- 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-4608) Update Log replay should use the default processor chain
[
https://issues.apache.org/jira/browse/SOLR-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609252#comment-13609252
]
Commit Tag Bot commented on SOLR-4608:
--
[branch_4x commit] Yonik Seeley
http://svn.apache.org/viewvc?view=revision&revision=1459427
SOLR-4608: use default update processor chain during log replay and peersync
> Update Log replay should use the default processor chain
>
>
> Key: SOLR-4608
> URL: https://issues.apache.org/jira/browse/SOLR-4608
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.1, 4.2
>Reporter: ludovic Boutros
>Assignee: Yonik Seeley
> Fix For: 4.3, 5.0, 4.2.1
>
> Attachments: SOLR-4608.patch
>
>
> If a processor chain is used with custom processors,
> they are not used in case of node failure during log replay.
> Here is the code:
> {code:title=UpdateLog.java|borderStyle=solid}
> public void doReplay(TransactionLog translog) {
> try {
> loglog.warn("Starting log replay " + translog + " active="+activeLog
> + " starting pos=" + recoveryInfo.positionOfStart);
> tlogReader = translog.getReader(recoveryInfo.positionOfStart);
> // NOTE: we don't currently handle a core reload during recovery.
> This would cause the core
> // to change underneath us.
> // TODO: use the standard request factory? We won't get any custom
> configuration instantiating this way.
> RunUpdateProcessorFactory runFac = new RunUpdateProcessorFactory();
> DistributedUpdateProcessorFactory magicFac = new
> DistributedUpdateProcessorFactory();
> runFac.init(new NamedList());
> magicFac.init(new NamedList());
> UpdateRequestProcessor proc = magicFac.getInstance(req, rsp,
> runFac.getInstance(req, rsp, null));
> {code}
> I think this is a big issue, because a lot of people will discover it when a
> node will crash in the best case... and I think it's too late.
> It means to me that processor chains are not usable with Solr Cloud currently.
>
--
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] (LUCENE-4848) Fix Directory implementations to use NIO2 APIs
[
https://issues.apache.org/jira/browse/LUCENE-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609242#comment-13609242
]
Uwe Schindler commented on LUCENE-4848:
---
I finally did some tests before committing:
- It is possible with NIOFSDirectory to open an IndexReader and after that
remove all files in Windows. The IndexReader is still working as it should.
This mimics POSIX behaviour, so Lucene can get rid of files earlier when NIOFS
is used.
- With MMapDirectory, the file channel also has delete allowed, but the windows
documentation explicitly says:
http://msdn.microsoft.com/en-us/library/aa363915%28v=VS.85%29.aspx that mmapped
files cannot be deleted (the documentation is a bit unclear, but the "OR"
states both possibilities):
{quote}
The DeleteFile function fails if an application attempts to delete a file that
has other handles open for normal I/O or as a memory-mapped file
(FILE_SHARE_DELETE must have been specified when other handles were opened).
The DeleteFile function marks a file for deletion on close. Therefore, the file
deletion does not occur until the last handle to the file is closed. Subsequent
calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED.
{quote}
I will commit this now.
> Fix Directory implementations to use NIO2 APIs
> --
>
> Key: LUCENE-4848
> URL: https://issues.apache.org/jira/browse/LUCENE-4848
> Project: Lucene - Core
> Issue Type: Task
>Affects Versions: 5.0
>Reporter: Michael Poindexter
>Assignee: Uwe Schindler
>Priority: Minor
> Fix For: 5.0
>
> Attachments: jdk7directory.zip, LUCENE-4848-MMapDirectory.patch,
> LUCENE-4848.patch, LUCENE-4848.patch, LUCENE-4848.patch, LUCENE-4848.patch,
> LUCENE-4848.patch, LUCENE-4848.patch, LUCENE-4848.patch, LUCENE-4848.patch,
> LUCENE-4848.patch.txt
>
>
> I have implemented 3 Directory subclasses using NIO2 API's (available on
> JDK7). These may be suitable for inclusion in a Lucene contrib module.
> See the mailing list at http://lucene.markmail.org/thread/lrv7miivzmjm3ml5
> for more details about this code and the advantages it provides.
> The code is attached as a zip to this issue. I'll be happy to make any
> changes requested. I've included some minimal smoke tests, but any help in
> how to use the normal Lucene tests to perform more thorough testing would be
> appreciated.
--
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-4608) Update Log replay should use the default processor chain
[
https://issues.apache.org/jira/browse/SOLR-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-4608.
Resolution: Fixed
> Update Log replay should use the default processor chain
>
>
> Key: SOLR-4608
> URL: https://issues.apache.org/jira/browse/SOLR-4608
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.1, 4.2
>Reporter: ludovic Boutros
>Assignee: Yonik Seeley
> Fix For: 4.3, 5.0, 4.2.1
>
> Attachments: SOLR-4608.patch
>
>
> If a processor chain is used with custom processors,
> they are not used in case of node failure during log replay.
> Here is the code:
> {code:title=UpdateLog.java|borderStyle=solid}
> public void doReplay(TransactionLog translog) {
> try {
> loglog.warn("Starting log replay " + translog + " active="+activeLog
> + " starting pos=" + recoveryInfo.positionOfStart);
> tlogReader = translog.getReader(recoveryInfo.positionOfStart);
> // NOTE: we don't currently handle a core reload during recovery.
> This would cause the core
> // to change underneath us.
> // TODO: use the standard request factory? We won't get any custom
> configuration instantiating this way.
> RunUpdateProcessorFactory runFac = new RunUpdateProcessorFactory();
> DistributedUpdateProcessorFactory magicFac = new
> DistributedUpdateProcessorFactory();
> runFac.init(new NamedList());
> magicFac.init(new NamedList());
> UpdateRequestProcessor proc = magicFac.getInstance(req, rsp,
> runFac.getInstance(req, rsp, null));
> {code}
> I think this is a big issue, because a lot of people will discover it when a
> node will crash in the best case... and I think it's too late.
> It means to me that processor chains are not usable with Solr Cloud currently.
>
--
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] (LUCENE-4752) Merge segments to sort them
[ https://issues.apache.org/jira/browse/LUCENE-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609231#comment-13609231 ] Adrien Grand commented on LUCENE-4752: -- I plan to commit it tomorrow unless someone objects. > Merge segments to sort them > --- > > Key: LUCENE-4752 > URL: https://issues.apache.org/jira/browse/LUCENE-4752 > Project: Lucene - Core > Issue Type: New Feature > Components: core/index >Reporter: David Smiley >Assignee: Adrien Grand > Attachments: LUCENE-4752.patch, LUCENE-4752.patch, LUCENE-4752.patch, > LUCENE-4752.patch, LUCENE-4752.patch, LUCENE-4752.patch, LUCENE-4752.patch, > natural_10M_ingestion.log, sorting_10M_ingestion.log > > > It would be awesome if Lucene could write the documents out in a segment > based on a configurable order. This of course applies to merging segments > to. The benefit is increased locality on disk of documents that are likely to > be accessed together. This often applies to documents near each other in > time, but also spatially. -- 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-4622) deprecate usage of DEFAULT_HOST_CONTEXT and DEFAULT_HOST_PORT
[
https://issues.apache.org/jira/browse/SOLR-4622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609219#comment-13609219
]
Hoss Man commented on SOLR-4622:
Proposal...
1) change the example solr.xml on 4x and trunk to use the current hardcoded
defaults as defaults for ht sys properties...
{noformat}
-
+
{noformat}
2) change the 4x code that uses DEFAULT_HOST_CONTEXT and DEFAULT_HOST_PORT to
log a warning that they are deprecated if they are used, along with what their
values are and how/where to explicitly set them
3) change the trunk code that uses DEFAULT_HOST_CONTEXT and DEFAULT_HOST_PORT
to fail fast if they aren't specified in solr.xml.
> deprecate usage of DEFAULT_HOST_CONTEXT and DEFAULT_HOST_PORT
> -
>
> Key: SOLR-4622
> URL: https://issues.apache.org/jira/browse/SOLR-4622
> Project: Solr
> Issue Type: Improvement
>Reporter: Hoss Man
>Assignee: Hoss Man
>
> Frequently, people who try to use solr cloud in a differnet servlet container
> (or in a jetty other then the preconfigured one supplied) they can be easily
> confused as to why/how/where solr is trying to hostContext=solr and
> hostPort=8983.
> these can be explicitly overridden in solr.xml, and the defaults are setup to
> read from system properties, but we should eliminate the hardcoded defaults
> from the java code (where most users can't even grep for them) and instead
> specify defaults for the sys properties in the example configs.
--
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-4608) Update Log replay should use the default processor chain
[
https://issues.apache.org/jira/browse/SOLR-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609216#comment-13609216
]
Commit Tag Bot commented on SOLR-4608:
--
[trunk commit] Yonik Seeley
http://svn.apache.org/viewvc?view=revision&revision=1459424
SOLR-4608: use default update processor chain during log replay and peersync
> Update Log replay should use the default processor chain
>
>
> Key: SOLR-4608
> URL: https://issues.apache.org/jira/browse/SOLR-4608
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.1, 4.2
>Reporter: ludovic Boutros
>Assignee: Yonik Seeley
> Fix For: 4.3, 5.0, 4.2.1
>
> Attachments: SOLR-4608.patch
>
>
> If a processor chain is used with custom processors,
> they are not used in case of node failure during log replay.
> Here is the code:
> {code:title=UpdateLog.java|borderStyle=solid}
> public void doReplay(TransactionLog translog) {
> try {
> loglog.warn("Starting log replay " + translog + " active="+activeLog
> + " starting pos=" + recoveryInfo.positionOfStart);
> tlogReader = translog.getReader(recoveryInfo.positionOfStart);
> // NOTE: we don't currently handle a core reload during recovery.
> This would cause the core
> // to change underneath us.
> // TODO: use the standard request factory? We won't get any custom
> configuration instantiating this way.
> RunUpdateProcessorFactory runFac = new RunUpdateProcessorFactory();
> DistributedUpdateProcessorFactory magicFac = new
> DistributedUpdateProcessorFactory();
> runFac.init(new NamedList());
> magicFac.init(new NamedList());
> UpdateRequestProcessor proc = magicFac.getInstance(req, rsp,
> runFac.getInstance(req, rsp, null));
> {code}
> I think this is a big issue, because a lot of people will discover it when a
> node will crash in the best case... and I think it's too late.
> It means to me that processor chains are not usable with Solr Cloud currently.
>
--
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-4622) deprecate usage of DEFAULT_HOST_CONTEXT and DEFAULT_HOST_PORT
Hoss Man created SOLR-4622: -- Summary: deprecate usage of DEFAULT_HOST_CONTEXT and DEFAULT_HOST_PORT Key: SOLR-4622 URL: https://issues.apache.org/jira/browse/SOLR-4622 Project: Solr Issue Type: Improvement Reporter: Hoss Man Assignee: Hoss Man Frequently, people who try to use solr cloud in a differnet servlet container (or in a jetty other then the preconfigured one supplied) they can be easily confused as to why/how/where solr is trying to hostContext=solr and hostPort=8983. these can be explicitly overridden in solr.xml, and the defaults are setup to read from system properties, but we should eliminate the hardcoded defaults from the java code (where most users can't even grep for them) and instead specify defaults for the sys properties in the example configs. -- 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] (LUCENE-4862) Ability to terminate queries on a per-segment basis
[ https://issues.apache.org/jira/browse/LUCENE-4862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609186#comment-13609186 ] Commit Tag Bot commented on LUCENE-4862: [branch_4x commit] Adrien Grand http://svn.apache.org/viewvc?view=revision&revision=1459416 LUCENE-4862: Test early termination with executor services too (merged from r1459414). > Ability to terminate queries on a per-segment basis > --- > > Key: LUCENE-4862 > URL: https://issues.apache.org/jira/browse/LUCENE-4862 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Fix For: 4.3 > > Attachments: LUCENE-4862.patch > > > Spin-off of LUCENE-4752. The idea is to add a marker exception that tells > IndexSearcher to terminate the collection of the current segment. -- 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] (LUCENE-4862) Ability to terminate queries on a per-segment basis
[ https://issues.apache.org/jira/browse/LUCENE-4862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609157#comment-13609157 ] Commit Tag Bot commented on LUCENE-4862: [trunk commit] Adrien Grand http://svn.apache.org/viewvc?view=revision&revision=1459414 LUCENE-4862: Test early termination with executor services too. > Ability to terminate queries on a per-segment basis > --- > > Key: LUCENE-4862 > URL: https://issues.apache.org/jira/browse/LUCENE-4862 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Fix For: 4.3 > > Attachments: LUCENE-4862.patch > > > Spin-off of LUCENE-4752. The idea is to add a marker exception that tells > IndexSearcher to terminate the collection of the current segment. -- 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] (LUCENE-4862) Ability to terminate queries on a per-segment basis
[ https://issues.apache.org/jira/browse/LUCENE-4862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609153#comment-13609153 ] Commit Tag Bot commented on LUCENE-4862: [branch_4x commit] Adrien Grand http://svn.apache.org/viewvc?view=revision&revision=1459408 LUCENE-4862: Added CollectionTerminatedException to allow permature termination of the collection of a single IndexReader leaf (merged from r1459400). > Ability to terminate queries on a per-segment basis > --- > > Key: LUCENE-4862 > URL: https://issues.apache.org/jira/browse/LUCENE-4862 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Fix For: 4.3 > > Attachments: LUCENE-4862.patch > > > Spin-off of LUCENE-4752. The idea is to add a marker exception that tells > IndexSearcher to terminate the collection of the current segment. -- 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: svn commit: r1459400 - in /lucene/dev/trunk/lucene: ./ core/src/java/org/apache/lucene/search/ core/src/test/org/apache/lucene/search/
On Thu, Mar 21, 2013 at 6:18 PM, Robert Muir wrote: > Its not clear to me that this works when IndexSearcher has an executorService. It works because the executed callables use the IndexSearcher.search wich has been modified to deal with CollectionTerminatedException (they just pass a singleton leaf context instead of all the reader's leaves). > can the test use newSearcher or something? Good point, I didn't know about this method. I'll improve the test. -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1459400 - in /lucene/dev/trunk/lucene: ./ core/src/java/org/apache/lucene/search/ core/src/test/org/apache/lucene/search/
Its not clear to me that this works when IndexSearcher has an executorService.
maybe it does.. but can the test use newSearcher or something?
On Thu, Mar 21, 2013 at 1:04 PM, wrote:
> Author: jpountz
> Date: Thu Mar 21 17:04:10 2013
> New Revision: 1459400
>
> URL: http://svn.apache.org/r1459400
> Log:
> LUCENE-4862: Added CollectionTerminatedException to allow permature
> termination of the collection of a single IndexReader leaf.
>
> Added:
>
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/CollectionTerminatedException.java
>(with props)
>
> lucene/dev/trunk/lucene/core/src/test/org/apache/lucene/search/TestEarlyTermination.java
>(with props)
> Modified:
> lucene/dev/trunk/lucene/CHANGES.txt
>
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/Collector.java
>
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/IndexSearcher.java
>
> Modified: lucene/dev/trunk/lucene/CHANGES.txt
> URL:
> http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/CHANGES.txt?rev=1459400&r1=1459399&r2=1459400&view=diff
> ==
> --- lucene/dev/trunk/lucene/CHANGES.txt (original)
> +++ lucene/dev/trunk/lucene/CHANGES.txt Thu Mar 21 17:04:10 2013
> @@ -116,6 +116,10 @@ New Features
> * LUCENE-4859: IndexReader now exposes Terms statistics: getDocCount,
>getSumDocFreq, getSumTotalTermFreq. (Shai Erera)
>
> +* LUCENE-4862: It is now possible to terminate collection of a single
> + IndexReader leaf by throwing a CollectionTerminatedException in
> + Collector.collect. (Adrien Grand, Shai Erera)
> +
> API Changes
>
> * LUCENE-4844: removed TaxonomyReader.getParent(), you should use
>
> Added:
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/CollectionTerminatedException.java
> URL:
> http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/CollectionTerminatedException.java?rev=1459400&view=auto
> ==
> ---
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/CollectionTerminatedException.java
> (added)
> +++
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/CollectionTerminatedException.java
> Thu Mar 21 17:04:10 2013
> @@ -0,0 +1,34 @@
> +package org.apache.lucene.search;
> +
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License. You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +
> +/** Throw this exception in {@link Collector#collect(int)} to prematurely
> + * terminate collection of the current leaf.
> + * Note: IndexSearcher swallows this exception and never re-throws it.
> + * As a consequence, you should not catch it when calling
> + * {@link IndexSearcher#search} as it is unnecessary and might hide misuse
> + * of this exception. */
> +@SuppressWarnings("serial")
> +public final class CollectionTerminatedException extends RuntimeException {
> +
> + /** Sole constructor. */
> + public CollectionTerminatedException() {
> +super();
> + }
> +
> +}
>
> Modified:
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/Collector.java
> URL:
> http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/Collector.java?rev=1459400&r1=1459399&r2=1459400&view=diff
> ==
> ---
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/Collector.java
> (original)
> +++
> lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/search/Collector.java
> Thu Mar 21 17:04:10 2013
> @@ -134,7 +134,10 @@ public abstract class Collector {
>/**
> * Called once for every document matching a query, with the unbased
> document
> * number.
> - *
> + * Note: The collection of the current segment can be terminated by
> throwing
> + * a {@link CollectionTerminatedException}. In this case, the last docs of
> the
> + * current {@link AtomicReaderContext} will be skipped and {@link
> IndexSearcher}
> + * will swallow the exception and continue collection with the next leaf.
> *
> * Note: This is called in an inner search loop. For good sea
[jira] [Resolved] (LUCENE-4862) Ability to terminate queries on a per-segment basis
[ https://issues.apache.org/jira/browse/LUCENE-4862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-4862. -- Resolution: Fixed Thank you for the review Shai! > Ability to terminate queries on a per-segment basis > --- > > Key: LUCENE-4862 > URL: https://issues.apache.org/jira/browse/LUCENE-4862 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Fix For: 4.3 > > Attachments: LUCENE-4862.patch > > > Spin-off of LUCENE-4752. The idea is to add a marker exception that tells > IndexSearcher to terminate the collection of the current segment. -- 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] (LUCENE-4862) Ability to terminate queries on a per-segment basis
[ https://issues.apache.org/jira/browse/LUCENE-4862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609131#comment-13609131 ] Commit Tag Bot commented on LUCENE-4862: [trunk commit] Adrien Grand http://svn.apache.org/viewvc?view=revision&revision=1459400 LUCENE-4862: Added CollectionTerminatedException to allow permature termination of the collection of a single IndexReader leaf. > Ability to terminate queries on a per-segment basis > --- > > Key: LUCENE-4862 > URL: https://issues.apache.org/jira/browse/LUCENE-4862 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Fix For: 4.3 > > Attachments: LUCENE-4862.patch > > > Spin-off of LUCENE-4752. The idea is to add a marker exception that tells > IndexSearcher to terminate the collection of the current segment. -- 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] (LUCENE-4867) SorterTemplate.merge is slow
[ https://issues.apache.org/jira/browse/LUCENE-4867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-4867: - Attachment: LUCENE-4867.patch Patch that makes SorterTemplate.merge protected and makes ArrayUtil and CollectionUtil use specialized SorterTemplate instances that use up to 1% extra memory for faster merge-based sorts. I'll open a separate issue to use the same optimizations for the sorter API's timsorts. > SorterTemplate.merge is slow > > > Key: LUCENE-4867 > URL: https://issues.apache.org/jira/browse/LUCENE-4867 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Attachments: LUCENE-4867.patch, LUCENE-4867.patch, SortBench.java > > > SorterTemplate.mergeSort/timSort can be very slow. For example, I ran a quick > benchmark that sorts an Integer[] array of 50M elements, and mergeSort was > almost 4x slower than quickSort (~12.8s for quickSort, ~46.5s for mergeSort). > This is even worse when the cost of a swap is higher (e.g. parallel arrays). > This is due to SorterTemplate.merge. I first feared that this method might > not be linear, but it is, so the slowness is due to the fact that this method > needs to swap lots of values in order not to require extra memory. Could we > make it faster? > For reference, I hacked a SorterTemplate instance to use the usual merge > routine (that requires n/2 elements in memory), and it was much faster: ~17s > on average, so there is room for improvement. -- 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
