[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-fcs-b132) - Build # 9831 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9831/
Java: 64bit/jdk1.8.0-fcs-b132 -XX:-UseCompressedOops -XX:+UseSerialGC
1 tests failed.
FAILED:
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.testWithin
{#4 seed=[25E057BEF603A59:3621DA68E80BD686]}
Error Message:
Shouldn't match I#0:Rect(minX=0.0,maxX=256.0,minY=-128.0,maxY=128.0)
Q:ShapePair(Rect(minX=0.0,maxX=256.0,minY=-128.0,maxY=128.0) ,
Rect(minX=38.0,maxX=47.0,minY=-67.0,maxY=-59.0))
Stack Trace:
java.lang.AssertionError: Shouldn't match
I#0:Rect(minX=0.0,maxX=256.0,minY=-128.0,maxY=128.0)
Q:ShapePair(Rect(minX=0.0,maxX=256.0,minY=-128.0,maxY=128.0) ,
Rect(minX=38.0,maxX=47.0,minY=-67.0,maxY=-59.0))
at
__randomizedtesting.SeedInfo.seed([25E057BEF603A59:3621DA68E80BD686]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.fail(SpatialOpRecursivePrefixTreeTest.java:355)
at
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.doTest(SpatialOpRecursivePrefixTreeTest.java:335)
at
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.testWithin(SpatialOpRecursivePrefixTreeTest.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1617)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:826)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:862)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359)
at java.lang.Thread.run(Thread.java:744)
[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_51) - Build # 9725 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9725/
Java: 32bit/jdk1.7.0_51 -server -XX:+UseSerialGC
2 tests failed.
FAILED:
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.testContains
{#7 seed=[175A10038A619363:146B27D88CDE16A]}
Error Message:
Shouldn't match I#0:Rect(minX=-180.0,maxX=180.0,minY=-90.0,maxY=90.0)
Q:ShapePair(Rect(minX=-180.0,maxX=180.0,minY=-90.0,maxY=90.0) ,
Rect(minX=-21.0,maxX=-14.0,minY=-26.0,maxY=-21.0))
Stack Trace:
java.lang.AssertionError: Shouldn't match
I#0:Rect(minX=-180.0,maxX=180.0,minY=-90.0,maxY=90.0)
Q:ShapePair(Rect(minX=-180.0,maxX=180.0,minY=-90.0,maxY=90.0) ,
Rect(minX=-21.0,maxX=-14.0,minY=-26.0,maxY=-21.0))
at
__randomizedtesting.SeedInfo.seed([175A10038A619363:146B27D88CDE16A]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.fail(SpatialOpRecursivePrefixTreeTest.java:355)
at
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.doTest(SpatialOpRecursivePrefixTreeTest.java:335)
at
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.testContains(SpatialOpRecursivePrefixTreeTest.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1617)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:826)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:862)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359)
at java.lang.Thread.run(Thread.java:744)
FAILED:
[jira] [Commented] (SOLR-1604) Wildcards, ORs etc inside Phrase Queries
[ https://issues.apache.org/jira/browse/SOLR-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1393#comment-1393 ] Anonymous commented on SOLR-1604: - Hey, I am using ComplexPhrase 4.2.1 with solr 4.7.0 Is there any difference between ComplexPhrase 4.7.0 and ComplexPhrase 4.2.1? And also Can I run this type of query hello world h* with this parser? Wildcards, ORs etc inside Phrase Queries Key: SOLR-1604 URL: https://issues.apache.org/jira/browse/SOLR-1604 Project: Solr Issue Type: Improvement Components: query parsers, search Affects Versions: 1.4 Reporter: Ahmet Arslan Assignee: Erick Erickson Priority: Minor Fix For: 4.8, 5.0 Attachments: ASF.LICENSE.NOT.GRANTED--ComplexPhrase.zip, ComplexPhrase-4.2.1.zip, ComplexPhrase-4.7.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhraseQueryParser.java, ComplexPhrase_solr_3.4.zip, SOLR-1604-alternative.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR1604.patch Solr Plugin for ComplexPhraseQueryParser (LUCENE-1486) which supports wildcards, ORs, ranges, fuzzies inside phrase queries. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.7-Linux (32bit/jdk1.8.0-fcs-b132) - Build # 1 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.7-Linux/1/ Java: 32bit/jdk1.8.0-fcs-b132 -client -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.lucene.index.TestCheckIndex.testLuceneConstantVersion Error Message: Invalid version: 4.7.1 Stack Trace: java.lang.AssertionError: Invalid version: 4.7.1 at __randomizedtesting.SeedInfo.seed([2652EE996AC62127:E5CC19574CD9C1E8]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.lucene.index.TestCheckIndex.testLuceneConstantVersion(TestCheckIndex.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:744) Build Log: [...truncated 10211 lines...] [junit4] Suite: org.apache.lucene.index.TestCheckIndex [junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestCheckIndex -Dtests.method=testLuceneConstantVersion -Dtests.seed=2652EE996AC62127 -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=es_GT -Dtests.timezone=Asia/Baghdad -Dtests.file.encoding=UTF-8 [junit4] FAILURE 0.01s J1 | TestCheckIndex.testLuceneConstantVersion [junit4] Throwable #1: java.lang.AssertionError: Invalid version: 4.7.1
[jira] [Updated] (SOLR-5876) createCollection(String name, String shards, Integer repl, Integer maxShards, String conf, String routerField, SolrServer server) appears to call itself.
[ https://issues.apache.org/jira/browse/SOLR-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-5876: --- Attachment: SOLR-5876.patch Patch with some extra cleanup of imports in a related test. createCollection(String name, String shards, Integer repl, Integer maxShards, String conf, String routerField, SolrServer server) appears to call itself. --- Key: SOLR-5876 URL: https://issues.apache.org/jira/browse/SOLR-5876 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.8, 5.0 Attachments: SOLR-5876.patch Causes an infinite recursion. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5205) [PATCH] SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13938895#comment-13938895 ] Anonymous commented on LUCENE-5205: --- Hey Tim, Can this parser handles query like hello world h* expected results sentences like hello world hello,hello world hey etc. I am using ComplexPhraseQuery Parser now but not able to get expected results of the above query. Thanks, Any help will be appreciated. [PATCH] SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser --- Key: LUCENE-5205 URL: https://issues.apache.org/jira/browse/LUCENE-5205 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Reporter: Tim Allison Labels: patch Fix For: 4.8 Attachments: LUCENE-5205-cleanup-tests.patch, LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, LUCENE-5205_dateTestReInitPkgPrvt.patch, LUCENE-5205_improve_stop_word_handling.patch, LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, SpanQueryParser_v1.patch.gz, patch.txt This parser extends QueryParserBase and includes functionality from: * Classic QueryParser: most of its syntax * SurroundQueryParser: recursive parsing for near and not clauses. * ComplexPhraseQueryParser: can handle near queries that include multiterms (wildcard, fuzzy, regex, prefix), * AnalyzingQueryParser: has an option to analyze multiterms. At a high level, there's a first pass BooleanQuery/field parser and then a span query parser handles all terminal nodes and phrases. Same as classic syntax: * term: test * fuzzy: roam~0.8, roam~2 * wildcard: te?t, test*, t*st * regex: /\[mb\]oat/ * phrase: jakarta apache * phrase with slop: jakarta apache~3 * default or clause: jakarta apache * grouping or clause: (jakarta apache) * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta * multiple fields: title:lucene author:hatcher Main additions in SpanQueryParser syntax vs. classic syntax: * Can require in order for phrases with slop with the \~ operator: jakarta apache\~3 * Can specify not near: fever bieber!\~3,10 :: find fever but not if bieber appears within 3 words before or 10 words after it. * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta apache\]~3 lucene\]\~4 :: find jakarta within 3 words of apache, and that hit has to be within four words before lucene * Can also use \[\] for single level phrasal queries instead of as in: \[jakarta apache\] * Can use or grouping clauses in phrasal queries: apache (lucene solr)\~3 :: find apache and then either lucene or solr within three words. * Can use multiterms in phrasal queries: jakarta\~1 ap*che\~2 * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like jakarta within two words of ap*che and that hit has to be within ten words of something like solr or that lucene regex. * Can require at least x number of hits at boolean level: apache AND (lucene solr tika)~2 * Can use negative only query: -jakarta :: Find all docs that don't contain jakarta * Can use an edit distance 2 for fuzzy query via SlowFuzzyQuery (beware of potential performance issues!). Trivial additions: * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, prefix =2) * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance =2: (jakarta~1 (OSA) vs jakarta~1(Levenshtein) This parser can be very useful for concordance tasks (see also LUCENE-5317 and LUCENE-5318) and for analytical search. Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery. Most of the documentation is in the javadoc for SpanQueryParser. Any and all feedback is welcome. Thank you. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_51) - Build # 9828 - Failure!
Build #9828 (17.03.2014 22:35:20) http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9828/ Java: 32bit/jdk1.7.0_51 -server -XX:+UseG1GC Build-Artefacts: junit4-J0-20140317_230107_233.events8.17 GB [fingerprint] view junit4-J1-20140317_230107_233.events61.65 MB[fingerprint] view This build created a 8.17 GB big events file and failed with out of space. How can this happen? Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de] Sent: Tuesday, March 18, 2014 2:26 AM To: dev@lucene.apache.org; steff...@apache.org; rm...@apache.org Subject: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_51) - Build # 9828 - Failure! Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9828/ Java: 32bit/jdk1.7.0_51 -server -XX:+UseG1GC All tests passed Build Log: [...truncated 12076 lines...] [junit4] JVM J0: stderr was not empty, see: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr- core/test/temp/junit4-J0-20140317_230107_233.syserr [junit4] JVM J0: stderr (verbatim) [junit4] WARN: Unhandled exception in event serialization. - com.carrotsearch.ant.tasks.junit4.dependencies.com.google.gson.JsonIOExc eption: java.io.IOException: No space left on device [junit4] at com.carrotsearch.ant.tasks.junit4.dependencies.com.google.gson.Gson.toJs on(Gson.java:514) [junit4] at com.carrotsearch.ant.tasks.junit4.events.Serializer.serialize(Serializer.java:61 ) [junit4] at com.carrotsearch.ant.tasks.junit4.slave.SlaveMain$4.write(SlaveMain.java:3 76) [junit4] at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) [junit4] at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) [junit4] at java.io.PrintStream.flush(PrintStream.java:338) [junit4] at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297) [junit4] at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) [junit4] at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) [junit4] at org.apache.log4j.helpers.QuietWriter.flush(QuietWriter.java:59) [junit4] at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:324) [junit4] at org.apache.log4j.WriterAppender.append(WriterAppender.java:162) [junit4] at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251) [junit4] at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppende rs(AppenderAttachableImpl.java:66) [junit4] at org.apache.log4j.Category.callAppenders(Category.java:206) [junit4] at org.apache.log4j.Category.forcedLog(Category.java:391) [junit4] at org.apache.log4j.Category.log(Category.java:856) [junit4] at org.slf4j.impl.Log4jLoggerAdapter.warn(Log4jLoggerAdapter.java:478) [junit4] at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest$FullThrottleStopableI ndexingThread$1.handleError(ChaosMonkeyNothingIsSafeTest.java:284) [junit4] at org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(C oncurrentUpdateSolrServer.java:256) [junit4] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav a:1145) [junit4] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja va:615) [junit4] at java.lang.Thread.run(Thread.java:744) [junit4] Caused by: java.io.IOException: No space left on device [junit4] at java.io.RandomAccessFile.writeBytes0(Native Method) [junit4] at java.io.RandomAccessFile.writeBytes(RandomAccessFile.java:520) [junit4] at java.io.RandomAccessFile.write(RandomAccessFile.java:550) [junit4] at com.carrotsearch.ant.tasks.junit4.slave.RandomAccessFileOutputStream.wri te(RandomAccessFileOutputStream.java:28) [junit4] at java.io.BufferedOutputStream.write(BufferedOutputStream.java:122) [junit4] at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) [junit4] at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:282) [junit4] at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125) [junit4] at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:113) [junit4] at java.io.OutputStreamWriter.write(OutputStreamWriter.java:194) [junit4] at com.carrotsearch.ant.tasks.junit4.dependencies.com.google.gson.stream.Js onWriter.string(JsonWriter.java:535) [junit4] at com.carrotsearch.ant.tasks.junit4.dependencies.com.google.gson.stream.Js onWriter.value(JsonWriter.java:364) [junit4] at com.carrotsearch.ant.tasks.junit4.dependencies.com.google.gson.internal.bi nd.TypeAdapters$22.write(TypeAdapters.java:626) [junit4] at com.carrotsearch.ant.tasks.junit4.dependencies.com.google.gson.internal.bi nd.TypeAdapters$22.write(TypeAdapters.java:578) [junit4] at
[jira] [Commented] (SOLR-5876) createCollection(String name, String shards, Integer repl, Integer maxShards, String conf, String routerField, SolrServer server) appears to call itself.
[ https://issues.apache.org/jira/browse/SOLR-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13938920#comment-13938920 ] ASF subversion and git services commented on SOLR-5876: --- Commit 1578775 from [~anshumg] in branch 'dev/trunk' [ https://svn.apache.org/r1578775 ] SOLR-5876: Fix self-calling createCollection(..) function. createCollection(String name, String shards, Integer repl, Integer maxShards, String conf, String routerField, SolrServer server) appears to call itself. --- Key: SOLR-5876 URL: https://issues.apache.org/jira/browse/SOLR-5876 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.8, 5.0 Attachments: SOLR-5876.patch Causes an infinite recursion. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5876) createCollection(String name, String shards, Integer repl, Integer maxShards, String conf, String routerField, SolrServer server) appears to call itself.
[ https://issues.apache.org/jira/browse/SOLR-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13938921#comment-13938921 ] ASF subversion and git services commented on SOLR-5876: --- Commit 1578776 from [~anshumg] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1578776 ] SOLR-5876: Fix self-calling createCollection(..) function. (Merging r1578775 from trunk) createCollection(String name, String shards, Integer repl, Integer maxShards, String conf, String routerField, SolrServer server) appears to call itself. --- Key: SOLR-5876 URL: https://issues.apache.org/jira/browse/SOLR-5876 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.8, 5.0 Attachments: SOLR-5876.patch Causes an infinite recursion. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [JENKINS] Lucene-Solr-4.7-Linux (32bit/jdk1.8.0-fcs-b132) - Build # 1 - Failure!
Hi, I have the feeling that this test is buggy. LUCENE_MAIN_VERSION must be in format x.y (2 digits!), but its somehow compares with the lucene version as passed in by sysproperty. I think this test should more or less only test that the MAIN_VERSION has 2 digits and starts with the correct prefix. I hate this test, it is always not understandable what happens, have to debug again. I wonder how this has passed in 4.6.1 Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de] Sent: Tuesday, March 18, 2014 7:49 AM To: dev@lucene.apache.org Subject: [JENKINS] Lucene-Solr-4.7-Linux (32bit/jdk1.8.0-fcs-b132) - Build # 1 - Failure! Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.7-Linux/1/ Java: 32bit/jdk1.8.0-fcs-b132 -client -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.lucene.index.TestCheckIndex.testLuceneConstantVersion Error Message: Invalid version: 4.7.1 Stack Trace: java.lang.AssertionError: Invalid version: 4.7.1 at __randomizedtesting.SeedInfo.seed([2652EE996AC62127:E5CC19574CD9C1E 8]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.lucene.index.TestCheckIndex.testLuceneConstantVersion(TestC heckIndex.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j ava:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize dRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(Rando mizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando mizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando mizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando mizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule SetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCa cheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA fterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1 .evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleTh readAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule IgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure .java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat ementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner. run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask (ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL eakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran domizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(Rando mizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(Rando mizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando mizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA fterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCl assName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1 .evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat ementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAss ertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure .java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule IgnoreAfterMaxFailures.java:70) at
RE: [JENKINS] Lucene-Solr-4.7-Linux (32bit/jdk1.8.0-fcs-b132) - Build # 1 - Failure!
I know why this passed with 4.6.1: We never changed the dev.version in this branch (it always stayed @ 4.6. The official bugfix number was added only while building the artifacts with -Dversion=4.6.1). This time Steve changed the version in build.xml to 4.7.1, and this is why the test fails. This is clearly a bug in the test, but on the other hand, we should somehow decide how to handle those version number, especially when to update them. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Uwe Schindler [mailto:u...@thetaphi.de] Sent: Tuesday, March 18, 2014 8:34 AM To: dev@lucene.apache.org Subject: RE: [JENKINS] Lucene-Solr-4.7-Linux (32bit/jdk1.8.0-fcs-b132) - Build # 1 - Failure! Hi, I have the feeling that this test is buggy. LUCENE_MAIN_VERSION must be in format x.y (2 digits!), but its somehow compares with the lucene version as passed in by sysproperty. I think this test should more or less only test that the MAIN_VERSION has 2 digits and starts with the correct prefix. I hate this test, it is always not understandable what happens, have to debug again. I wonder how this has passed in 4.6.1 Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de] Sent: Tuesday, March 18, 2014 7:49 AM To: dev@lucene.apache.org Subject: [JENKINS] Lucene-Solr-4.7-Linux (32bit/jdk1.8.0-fcs-b132) - Build # 1 - Failure! Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.7-Linux/1/ Java: 32bit/jdk1.8.0-fcs-b132 -client -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.lucene.index.TestCheckIndex.testLuceneConstantVersion Error Message: Invalid version: 4.7.1 Stack Trace: java.lang.AssertionError: Invalid version: 4.7.1 at __randomizedtesting.SeedInfo.seed([2652EE996AC62127:E5CC19574CD9C1E 8]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.lucene.index.TestCheckIndex.testLuceneConstantVersion(TestC heckIndex.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j ava:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize dRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(Rando mizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando mizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando mizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando mizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRul e SetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFie ldCa cheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBefo reA fterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule $1 .evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleTh readAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestR ule IgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFail ure .java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Sta t ementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner. run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTas k (ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(Thread L eakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran domizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(Rando mizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(Rando mizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando mizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBefo reA fterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStore Cl assName.java:42) at
[jira] [Commented] (SOLR-5872) Eliminate overseer queue
[
https://issues.apache.org/jira/browse/SOLR-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13938943#comment-13938943
]
Shalin Shekhar Mangar commented on SOLR-5872:
-
{quote}
bq. as we move the individual collection states out of the main
clusterstate.json [...]
This will make a difference on clusters with many smaller collections, but not
on the single big collection.
It seems like we still want scalability in both directions (wrt number of
collections, and the size a single collection can be).
{quote}
The best solution that I see here is to move the replica states out into their
own ZK nodes. This way the individual nodes can update them directly without
the overseer via compare and set operations. The rest of the operations can
continue to be processed in the overseer. If we do this, even the external
collection changes may not be required. The leader information can also be read
directly from the leader election nodes.
Eliminate overseer queue
-
Key: SOLR-5872
URL: https://issues.apache.org/jira/browse/SOLR-5872
Project: Solr
Issue Type: Improvement
Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
The overseer queue is one of the busiest points in the entire system. The
raison d'être of the queue is
* Provide batching of operations for the main clusterstate,json so that
state updates are minimized
* Avoid race conditions and ensure order
Now , as we move the individual collection states out of the main
clusterstate.json, the batching is not useful anymore.
Race conditions can easily be solved by using a compare and set in Zookeeper.
The proposed solution is , whenever an operation is required to be performed
on the clusterstate, the same thread (and of course the same JVM)
# read the fresh state and version of zk node
# construct the new state
# perform a compare and set
# if compare and set fails go to step 1
This should be limited to all operations performed on external collections
because batching would be required for others
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_51) - Build # 9828 - Failure!
junit4-J0-20140317_230107_233.events8.17 GB [fingerprint] view This build created a 8.17 GB big events file and failed with out of space. How can this happen? Can you peek at it? It's probably something that logs in a loop or something. I'm fetching it right now, let's see if I can figure it out. D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5763) Upgrade to Tika 1.5
[ https://issues.apache.org/jira/browse/SOLR-5763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-5763: --- Attachment: SOLR-5763.patch Updated versions and checksums: pdfbox 1.8.1 - 1.8.4 jempbox 1.8.1 - 1.8.4 fontbox 1.8.1 - 1.8.4 Upgrade to Tika 1.5 --- Key: SOLR-5763 URL: https://issues.apache.org/jira/browse/SOLR-5763 Project: Solr Issue Type: Task Components: contrib - Solr Cell (Tika extraction) Reporter: Steve Rowe Priority: Minor Attachments: SOLR-5763.patch, SOLR-5763.patch, SOLR-5763.patch Just released: http://www.apache.org/dist/tika/CHANGES-1.5.txt -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_51) - Build # 9828 - Failure!
I dig tail -1 to extract the last 1 lines. The file is also in the archive at same place. It is indeed a loop. The code loops endless in a Connection Refused loop, without any delay between the events. After approx. 2:50 hours this hit the limits of the SSD file system. This test fails so often since it was fixed, we should revert to @BadApple. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Tuesday, March 18, 2014 9:16 AM To: dev@lucene.apache.org Subject: Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_51) - Build # 9828 - Failure! junit4-J0-20140317_230107_233.events8.17 GB [fingerprint] view This build created a 8.17 GB big events file and failed with out of space. How can this happen? Can you peek at it? It's probably something that logs in a loop or something. I'm fetching it right now, let's see if I can figure it out. D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
License check fails in precommit
Hi I ran precommit and got license check failures for all the *1.6.6.jar files under solr/example/lib/ext. It looks like these are old jars as there's a matching 1.7.6 version for each of those. I can remove them, but anyone can tell me what should I run to make sure I didn't screw up anything? Shai
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_51) - Build # 9828 - Failure!
It's a lot of error messages like this one. I have the full syserr dump if needed. D. 2773140 T6223 oasc.ChaosMonkeyNothingIsSafeTest$FullThrottleStopableIndexingThread$1.handleError WARN suss error java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:579) at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:618) at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:522) at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:401) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:178) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:610) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:445) at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57) at org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:232) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) On Tue, Mar 18, 2014 at 9:46 AM, Uwe Schindler u...@thetaphi.de wrote: I dig tail -1 to extract the last 1 lines. The file is also in the archive at same place. It is indeed a loop. The code loops endless in a Connection Refused loop, without any delay between the events. After approx. 2:50 hours this hit the limits of the SSD file system. This test fails so often since it was fixed, we should revert to @BadApple. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Tuesday, March 18, 2014 9:16 AM To: dev@lucene.apache.org Subject: Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_51) - Build # 9828 - Failure! junit4-J0-20140317_230107_233.events8.17 GB [fingerprint] view This build created a 8.17 GB big events file and failed with out of space. How can this happen? Can you peek at it? It's probably something that logs in a loop or something. I'm fetching it right now, let's see if I can figure it out. D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5513) Binary DocValues Updates
[ https://issues.apache.org/jira/browse/LUCENE-5513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13938977#comment-13938977 ] ASF subversion and git services commented on LUCENE-5513: - Commit 1578784 from [~shaie] in branch 'dev/trunk' [ https://svn.apache.org/r1578784 ] LUCENE-5513: add IndexWriter.updateBinaryDocValue Binary DocValues Updates Key: LUCENE-5513 URL: https://issues.apache.org/jira/browse/LUCENE-5513 Project: Lucene - Core Issue Type: Wish Components: core/index Reporter: Mikhail Khludnev Priority: Minor Attachments: LUCENE-5513.patch, LUCENE-5513.patch, LUCENE-5513.patch, LUCENE-5513.patch LUCENE-5189 was a great move toward. I wish to continue. The reason for having this feature is to have join-index - to write children docnums into parent's binaryDV. I can try to proceed the implementation, but I'm not so experienced in such deep Lucene internals. [~shaie], any hint to begin with is much appreciated. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.7-Linux (32bit/jdk1.8.0-fcs-b132) - Build # 2 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.7-Linux/2/ Java: 32bit/jdk1.8.0-fcs-b132 -server -XX:+UseG1GC 1 tests failed. FAILED: org.apache.lucene.index.TestCheckIndex.testLuceneConstantVersion Error Message: Invalid version: 4.7.1 Stack Trace: java.lang.AssertionError: Invalid version: 4.7.1 at __randomizedtesting.SeedInfo.seed([B796EB739603D205:74081CBDB01C32CA]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.lucene.index.TestCheckIndex.testLuceneConstantVersion(TestCheckIndex.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:744) Build Log: [...truncated 1222 lines...] [junit4] Suite: org.apache.lucene.index.TestCheckIndex [junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestCheckIndex -Dtests.method=testLuceneConstantVersion -Dtests.seed=B796EB739603D205 -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=en_GB -Dtests.timezone=Africa/Bissau -Dtests.file.encoding=ISO-8859-1 [junit4] FAILURE 0.01s J0 | TestCheckIndex.testLuceneConstantVersion [junit4] Throwable #1: java.lang.AssertionError: Invalid version: 4.7.1
RE: License check fails in precommit
Ant clean-jars. This is a bug in Ivy, that it does not sync resources correctly if version numbers change. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de http://www.thetaphi.de/ eMail: u...@thetaphi.de From: Shai Erera [mailto:ser...@gmail.com] Sent: Tuesday, March 18, 2014 9:55 AM To: dev@lucene.apache.org Subject: License check fails in precommit Hi I ran precommit and got license check failures for all the *1.6.6.jar files under solr/example/lib/ext. It looks like these are old jars as there's a matching 1.7.6 version for each of those. I can remove them, but anyone can tell me what should I run to make sure I didn't screw up anything? Shai
Re: License check fails in precommit
Ahh thanks, I thought these files are checked in but I see they're indeed only in my local checkout. 'ant clean-jars' removed them. Thanks, Shai On Tue, Mar 18, 2014 at 11:13 AM, Uwe Schindler u...@thetaphi.de wrote: Ant clean-jars. This is a bug in Ivy, that it does not sync resources correctly if version numbers change. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de *From:* Shai Erera [mailto:ser...@gmail.com] *Sent:* Tuesday, March 18, 2014 9:55 AM *To:* dev@lucene.apache.org *Subject:* License check fails in precommit Hi I ran precommit and got license check failures for all the *1.6.6.jar files under solr/example/lib/ext. It looks like these are old jars as there's a matching 1.7.6 version for each of those. I can remove them, but anyone can tell me what should I run to make sure I didn't screw up anything? Shai
[jira] [Commented] (LUCENE-5513) Binary DocValues Updates
[ https://issues.apache.org/jira/browse/LUCENE-5513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13938992#comment-13938992 ] ASF subversion and git services commented on LUCENE-5513: - Commit 1578790 from [~shaie] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1578790 ] LUCENE-5513: add IndexWriter.updateBinaryDocValue Binary DocValues Updates Key: LUCENE-5513 URL: https://issues.apache.org/jira/browse/LUCENE-5513 Project: Lucene - Core Issue Type: Wish Components: core/index Reporter: Mikhail Khludnev Priority: Minor Attachments: LUCENE-5513.patch, LUCENE-5513.patch, LUCENE-5513.patch, LUCENE-5513.patch LUCENE-5189 was a great move toward. I wish to continue. The reason for having this feature is to have join-index - to write children docnums into parent's binaryDV. I can try to proceed the implementation, but I'm not so experienced in such deep Lucene internals. [~shaie], any hint to begin with is much appreciated. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5111) Fix WordDelimiterFilter
[ https://issues.apache.org/jira/browse/LUCENE-5111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13938991#comment-13938991 ] Michael McCandless commented on LUCENE-5111: +1 I use WDF at http://jirasearch.mikemccandless.com (for CamelCaseTokenization) ... very happy to see this finally getting fixed! Fix WordDelimiterFilter --- Key: LUCENE-5111 URL: https://issues.apache.org/jira/browse/LUCENE-5111 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Assignee: Adrien Grand Attachments: LUCENE-5111.patch WordDelimiterFilter is documented as broken is TestRandomChains (LUCENE-4641). Given how used it is, we should try to fix it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5513) Binary DocValues Updates
[ https://issues.apache.org/jira/browse/LUCENE-5513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-5513. Resolution: Fixed Fix Version/s: 5.0 4.8 Assignee: Shai Erera Lucene Fields: New,Patch Available (was: New) Committed to trunk and 4x. Thanks Mike for the review! Binary DocValues Updates Key: LUCENE-5513 URL: https://issues.apache.org/jira/browse/LUCENE-5513 Project: Lucene - Core Issue Type: Wish Components: core/index Reporter: Mikhail Khludnev Assignee: Shai Erera Priority: Minor Fix For: 4.8, 5.0 Attachments: LUCENE-5513.patch, LUCENE-5513.patch, LUCENE-5513.patch, LUCENE-5513.patch LUCENE-5189 was a great move toward. I wish to continue. The reason for having this feature is to have join-index - to write children docnums into parent's binaryDV. I can try to proceed the implementation, but I'm not so experienced in such deep Lucene internals. [~shaie], any hint to begin with is much appreciated. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-4x-Linux-Java7-64-test-only - Build # 16143 - Failure!
Build: builds.flonkings.com/job/Lucene-4x-Linux-Java7-64-test-only/16143/ 4 tests failed. FAILED: org.apache.lucene.index.TestMixedDocValuesUpdates.testManyReopensAndFields Error Message: file _0_dv.cfs was already written to Stack Trace: java.io.IOException: file _0_dv.cfs was already written to at __randomizedtesting.SeedInfo.seed([72E9F094840D6473:441592BB05F8076F]:0) at org.apache.lucene.store.MockDirectoryWrapper.createOutput(MockDirectoryWrapper.java:466) at org.apache.lucene.store.TrackingDirectoryWrapper.createOutput(TrackingDirectoryWrapper.java:44) at org.apache.lucene.store.CompoundFileWriter.getOutput(CompoundFileWriter.java:103) at org.apache.lucene.store.CompoundFileWriter.createOutput(CompoundFileWriter.java:231) at org.apache.lucene.store.CompoundFileDirectory.createOutput(CompoundFileDirectory.java:332) at org.apache.lucene.codecs.lucene40.Lucene40DocValuesWriter.addNumericField(Lucene40DocValuesWriter.java:65) at org.apache.lucene.index.ReadersAndUpdates.writeFieldUpdates(ReadersAndUpdates.java:412) at org.apache.lucene.index.BufferedUpdatesStream.applyDeletesAndUpdates(BufferedUpdatesStream.java:237) at org.apache.lucene.index.IndexWriter.applyAllDeletesAndUpdates(IndexWriter.java:3209) at org.apache.lucene.index.IndexWriter.maybeApplyDeletes(IndexWriter.java:3200) at org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:381) at org.apache.lucene.index.StandardDirectoryReader.doOpenFromWriter(StandardDirectoryReader.java:288) at org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:263) at org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:253) at org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:170) at org.apache.lucene.index.TestMixedDocValuesUpdates.testManyReopensAndFields(TestMixedDocValuesUpdates.java:138) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1617) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:826) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:862) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at
Solr component: Query Local Term Boosting (QLTB)
Hello all, We have written a SOLR component for configurable boosting of terms depending on the user query, and our company, solute GmbH / www.billiger.de, has allowed us to release this component under the Apache 2 License. So we proudly present: Query-Local Term Boost (QLTB) component. This component inserts boosted terms into the SOLR query depending on the query string. Each such query string and its boost terms (or block terms) are listed in one big XML file, the term boost map. In the prepare() stage, the user's query is analyzed and checked against the term boost map. If a matching entry is found, the request is rewritten: the original query put inside a new BooleanQuery as a MUST term, and the stored ConstantScoreQueries are added to this BooleanQuery as either SHOULD (boost 0) or MUST_NOT (boost = 0) terms. More docs is in the source code, available on Github: https://github.com/solute/qltb We would be thrilled to get your feedback. Cheers, Frank Honza, Jan Morlock, and Patrick Schemitz PS: Please note the Zookeeper code is untested: we don't use Zookeeper. -- billiger.de solute gmbh Zeppelinstraße 15 D-76185 Karlsruhe Tel: +49.(0)721.86956-23 Fax: +49.(0)721.86956-66 E-Mail: p...@solute.de _ Geschäftsführer: Lorenz Petersen Sitz: Karlsruhe Registergericht: Amtsgericht Mannheim Registernummer: HRB 110579 Umsatzsteueridentifikationsnummer: DE234663798 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5858) Specify highlight query parameter outside of localparams
[ https://issues.apache.org/jira/browse/SOLR-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939012#comment-13939012 ] ASF subversion and git services commented on SOLR-5858: --- Commit 1578800 from [~romseygeek] in branch 'dev/trunk' [ https://svn.apache.org/r1578800 ] SOLR-5858, SOLR-4812: Allow queryparser to be defined for highlight query, and edismax and dismax to be used for this purpose Specify highlight query parameter outside of localparams Key: SOLR-5858 URL: https://issues.apache.org/jira/browse/SOLR-5858 Project: Solr Issue Type: Improvement Affects Versions: 4.7, 5.0 Reporter: Alan Woodward Assignee: Alan Woodward Priority: Minor Fix For: 4.8 Attachments: SOLR-5858.patch, SOLR-5858.patch A separate highlight query provided by the hl.q parameter will always use the lucene query parser unless a separate parser is explicitly provided as a localparam. This is mildly annoying if you're using a hand-rolled query parser. This patch adds a new hl.qparser parameter that allows you to specify a query parser outside of localparams, and will fall back to using the overall query defType if hl.qparser is not passed. Patch also fixes a bug in edismax and dismax query parsers whereby they couldn't be used for highlight queries because they weren't properly set up until parse() is called, and HighlightComponent doesn't do that. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5858) Specify highlight query parameter outside of localparams
[ https://issues.apache.org/jira/browse/SOLR-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939014#comment-13939014 ] ASF subversion and git services commented on SOLR-5858: --- Commit 1578801 from [~romseygeek] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1578801 ] SOLR-5858, SOLR-4812: Allow queryparser to be defined for highlight query, and edismax and dismax to be used for this purpose Specify highlight query parameter outside of localparams Key: SOLR-5858 URL: https://issues.apache.org/jira/browse/SOLR-5858 Project: Solr Issue Type: Improvement Affects Versions: 4.7, 5.0 Reporter: Alan Woodward Assignee: Alan Woodward Priority: Minor Fix For: 4.8 Attachments: SOLR-5858.patch, SOLR-5858.patch A separate highlight query provided by the hl.q parameter will always use the lucene query parser unless a separate parser is explicitly provided as a localparam. This is mildly annoying if you're using a hand-rolled query parser. This patch adds a new hl.qparser parameter that allows you to specify a query parser outside of localparams, and will fall back to using the overall query defType if hl.qparser is not passed. Patch also fixes a bug in edismax and dismax query parsers whereby they couldn't be used for highlight queries because they weren't properly set up until parse() is called, and HighlightComponent doesn't do that. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4812) Edismax highlighting query doesn't work.
[
https://issues.apache.org/jira/browse/SOLR-4812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939015#comment-13939015
]
ASF subversion and git services commented on SOLR-4812:
---
Commit 1578801 from [~romseygeek] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1578801 ]
SOLR-5858, SOLR-4812: Allow queryparser to be defined for highlight query, and
edismax and dismax to be used for this purpose
Edismax highlighting query doesn't work.
Key: SOLR-4812
URL: https://issues.apache.org/jira/browse/SOLR-4812
Project: Solr
Issue Type: Bug
Affects Versions: 4.2, 4.3
Environment: When hl.q is a edismax query, Highligting will ignore
the query specified in hl.q
Reporter: Tien Nguyen Manh
Priority: Minor
Fix For: 4.8
Attachments: SOLR-4812.patch
When hl.q is an edismax query, Highligting will ignore the query specified in
hl.q
edismax highlighting query hl.q={!edismax qf=title v=Software}
function getHighlightQuery in edismax don't parse highlight query so it
always return null so hl.q is ignored.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4812) Edismax highlighting query doesn't work.
[
https://issues.apache.org/jira/browse/SOLR-4812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939013#comment-13939013
]
ASF subversion and git services commented on SOLR-4812:
---
Commit 1578800 from [~romseygeek] in branch 'dev/trunk'
[ https://svn.apache.org/r1578800 ]
SOLR-5858, SOLR-4812: Allow queryparser to be defined for highlight query, and
edismax and dismax to be used for this purpose
Edismax highlighting query doesn't work.
Key: SOLR-4812
URL: https://issues.apache.org/jira/browse/SOLR-4812
Project: Solr
Issue Type: Bug
Affects Versions: 4.2, 4.3
Environment: When hl.q is a edismax query, Highligting will ignore
the query specified in hl.q
Reporter: Tien Nguyen Manh
Priority: Minor
Fix For: 4.8
Attachments: SOLR-4812.patch
When hl.q is an edismax query, Highligting will ignore the query specified in
hl.q
edismax highlighting query hl.q={!edismax qf=title v=Software}
function getHighlightQuery in edismax don't parse highlight query so it
always return null so hl.q is ignored.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4812) Edismax highlighting query doesn't work.
[
https://issues.apache.org/jira/browse/SOLR-4812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Woodward resolved SOLR-4812.
-
Resolution: Fixed
Assignee: Alan Woodward
Edismax highlighting query doesn't work.
Key: SOLR-4812
URL: https://issues.apache.org/jira/browse/SOLR-4812
Project: Solr
Issue Type: Bug
Affects Versions: 4.2, 4.3
Environment: When hl.q is a edismax query, Highligting will ignore
the query specified in hl.q
Reporter: Tien Nguyen Manh
Assignee: Alan Woodward
Priority: Minor
Fix For: 4.8
Attachments: SOLR-4812.patch
When hl.q is an edismax query, Highligting will ignore the query specified in
hl.q
edismax highlighting query hl.q={!edismax qf=title v=Software}
function getHighlightQuery in edismax don't parse highlight query so it
always return null so hl.q is ignored.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5858) Specify highlight query parameter outside of localparams
[ https://issues.apache.org/jira/browse/SOLR-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved SOLR-5858. - Resolution: Fixed Specify highlight query parameter outside of localparams Key: SOLR-5858 URL: https://issues.apache.org/jira/browse/SOLR-5858 Project: Solr Issue Type: Improvement Affects Versions: 4.7, 5.0 Reporter: Alan Woodward Assignee: Alan Woodward Priority: Minor Fix For: 4.8 Attachments: SOLR-5858.patch, SOLR-5858.patch A separate highlight query provided by the hl.q parameter will always use the lucene query parser unless a separate parser is explicitly provided as a localparam. This is mildly annoying if you're using a hand-rolled query parser. This patch adds a new hl.qparser parameter that allows you to specify a query parser outside of localparams, and will fall back to using the overall query defType if hl.qparser is not passed. Patch also fixes a bug in edismax and dismax query parsers whereby they couldn't be used for highlight queries because they weren't properly set up until parse() is called, and HighlightComponent doesn't do that. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5513) Binary DocValues Updates
[ https://issues.apache.org/jira/browse/LUCENE-5513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939017#comment-13939017 ] ASF subversion and git services commented on LUCENE-5513: - Commit 1578803 from [~shaie] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1578803 ] LUCENE-5513: suppress codecs in test Binary DocValues Updates Key: LUCENE-5513 URL: https://issues.apache.org/jira/browse/LUCENE-5513 Project: Lucene - Core Issue Type: Wish Components: core/index Reporter: Mikhail Khludnev Assignee: Shai Erera Priority: Minor Fix For: 4.8, 5.0 Attachments: LUCENE-5513.patch, LUCENE-5513.patch, LUCENE-5513.patch, LUCENE-5513.patch LUCENE-5189 was a great move toward. I wish to continue. The reason for having this feature is to have join-index - to write children docnums into parent's binaryDV. I can try to proceed the implementation, but I'm not so experienced in such deep Lucene internals. [~shaie], any hint to begin with is much appreciated. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5489) Add query rescoring API
[ https://issues.apache.org/jira/browse/LUCENE-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-5489: --- Attachment: LUCENE-5489.patch New patch, just fixing javadocs / nocommits ... I think this is ready, and we can iterate later for future improvements. Add query rescoring API --- Key: LUCENE-5489 URL: https://issues.apache.org/jira/browse/LUCENE-5489 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.8, 5.0 Attachments: LUCENE-5489.patch, LUCENE-5489.patch When costly scoring factors are used during searching, a common approach is to do a cheaper / basic query first, collect the top few hundred hits, and then rescore those hits using the more costly query. It's not clear/simple to do this with Lucene today; I think we should make it easier. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5537) Fix version check in TestCheckIndexes
Uwe Schindler created LUCENE-5537: - Summary: Fix version check in TestCheckIndexes Key: LUCENE-5537 URL: https://issues.apache.org/jira/browse/LUCENE-5537 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 4.7 Reporter: Uwe Schindler Assignee: Uwe Schindler Priority: Blocker Fix For: 4.8, 5.0, 4.7.1 The crazy version check in TestCheckIndexes is broken. Whenever it fails, it requires a horrible amount of understanding: - error messages are useless - you don't know what it really checks and why (no documentation) In addition, we have no clear workflow how to handle version updates: - In 4.6 series we never set the dev.version in common-build to 4.6.1, it always stayed 4.6. The test worked therefore, because the LUCENE_MAIN_VERSION (which is always x.y) was identical - In 4.7 [~steve_rowe] changed the version to the real release version in the branch. The test failed because of this change (LUCENE_MAIN_VERSION was not identical as the dotted bugfix version) We should in any case fix the test: - move it out of TestCheckIndex, it should be in oal.util.TestConstants - Be more verbose on loggin - Remove special cases (leftovers from 4.0-BETA) where we did crazy stuff to make this test pass in alphas and betas. We should also document and write down when we change the version numbers. I would prefer to use the variant of Lucene 4.6: never change the version number in common-build and override it while building artifacts. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-4x-Linux-Java7-64-test-only - Build # 16144 - Still Failing!
Build: builds.flonkings.com/job/Lucene-4x-Linux-Java7-64-test-only/16144/ 4 tests failed. FAILED: org.apache.lucene.index.TestMixedDocValuesUpdates.testStressMultiThreading Error Message: file _0_dv.cfs was already written to Stack Trace: java.io.IOException: file _0_dv.cfs was already written to at org.apache.lucene.store.MockDirectoryWrapper.createOutput(MockDirectoryWrapper.java:466) at org.apache.lucene.store.TrackingDirectoryWrapper.createOutput(TrackingDirectoryWrapper.java:44) at org.apache.lucene.store.CompoundFileWriter.getOutput(CompoundFileWriter.java:103) at org.apache.lucene.store.CompoundFileWriter.createOutput(CompoundFileWriter.java:231) at org.apache.lucene.store.CompoundFileDirectory.createOutput(CompoundFileDirectory.java:332) at org.apache.lucene.codecs.lucene40.Lucene40DocValuesWriter.addNumericField(Lucene40DocValuesWriter.java:65) at org.apache.lucene.index.ReadersAndUpdates.writeFieldUpdates(ReadersAndUpdates.java:412) at org.apache.lucene.index.BufferedUpdatesStream.applyDeletesAndUpdates(BufferedUpdatesStream.java:237) at org.apache.lucene.index.IndexWriter.applyAllDeletesAndUpdates(IndexWriter.java:3209) at org.apache.lucene.index.IndexWriter.maybeApplyDeletes(IndexWriter.java:3200) at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3173) at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3141) at org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:983) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:927) at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:889) at org.apache.lucene.index.TestMixedDocValuesUpdates.testStressMultiThreading(TestMixedDocValuesUpdates.java:293) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1617) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:826) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:862) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Updated] (LUCENE-5537) Fix version check in TestCheckIndexes
[ https://issues.apache.org/jira/browse/LUCENE-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-5537: -- Description: The crazy version check in TestCheckIndexes is broken. Whenever it fails, it requires a horrible amount of understanding: - error messages are useless - you don't know what it really checks and why (no documentation) In addition, we have no clear workflow how to handle version updates: - In 4.6 series we never set the dev.version in common-build to 4.6.1, it always stayed 4.6. The test worked therefore, because the LUCENE_MAIN_VERSION (which is always x.y) was identical - In 4.7 [~steve_rowe] changed the version to the real release version in the branch. The test failed because of this change (LUCENE_MAIN_VERSION was not identical as the dotted bugfix version) We should in any case fix the test: - move it out of TestCheckIndex, it should be in oal.util.TestConstants - Be more verbose on loggin - Remove special cases (leftovers from 4.0-BETA) where we did crazy stuff to make this test pass in alphas and betas. - Only add a check to LUCENE_MAIN_VERSION that it is in format x.y (which is required by Lucene index format), and only check that it is the prefix of the real version as reported by common_build.xml. We should also document and write down when we change the version numbers. I would prefer to use the variant of Lucene 4.6: never change the version number in common-build and override it while building artifacts. was: The crazy version check in TestCheckIndexes is broken. Whenever it fails, it requires a horrible amount of understanding: - error messages are useless - you don't know what it really checks and why (no documentation) In addition, we have no clear workflow how to handle version updates: - In 4.6 series we never set the dev.version in common-build to 4.6.1, it always stayed 4.6. The test worked therefore, because the LUCENE_MAIN_VERSION (which is always x.y) was identical - In 4.7 [~steve_rowe] changed the version to the real release version in the branch. The test failed because of this change (LUCENE_MAIN_VERSION was not identical as the dotted bugfix version) We should in any case fix the test: - move it out of TestCheckIndex, it should be in oal.util.TestConstants - Be more verbose on loggin - Remove special cases (leftovers from 4.0-BETA) where we did crazy stuff to make this test pass in alphas and betas. We should also document and write down when we change the version numbers. I would prefer to use the variant of Lucene 4.6: never change the version number in common-build and override it while building artifacts. Fix version check in TestCheckIndexes - Key: LUCENE-5537 URL: https://issues.apache.org/jira/browse/LUCENE-5537 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 4.7 Reporter: Uwe Schindler Assignee: Uwe Schindler Priority: Blocker Fix For: 4.8, 5.0, 4.7.1 The crazy version check in TestCheckIndexes is broken. Whenever it fails, it requires a horrible amount of understanding: - error messages are useless - you don't know what it really checks and why (no documentation) In addition, we have no clear workflow how to handle version updates: - In 4.6 series we never set the dev.version in common-build to 4.6.1, it always stayed 4.6. The test worked therefore, because the LUCENE_MAIN_VERSION (which is always x.y) was identical - In 4.7 [~steve_rowe] changed the version to the real release version in the branch. The test failed because of this change (LUCENE_MAIN_VERSION was not identical as the dotted bugfix version) We should in any case fix the test: - move it out of TestCheckIndex, it should be in oal.util.TestConstants - Be more verbose on loggin - Remove special cases (leftovers from 4.0-BETA) where we did crazy stuff to make this test pass in alphas and betas. - Only add a check to LUCENE_MAIN_VERSION that it is in format x.y (which is required by Lucene index format), and only check that it is the prefix of the real version as reported by common_build.xml. We should also document and write down when we change the version numbers. I would prefer to use the variant of Lucene 4.6: never change the version number in common-build and override it while building artifacts. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.8.0-fcs-b132) - Build # 9727 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9727/
Java: 64bit/jdk1.8.0-fcs-b132 -XX:+UseCompressedOops -XX:+UseSerialGC
1 tests failed.
FAILED:
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.testContains
{#4 seed=[CA75DB0F916D04D4:EFFE54D2DF59BF75]}
Error Message:
Shouldn't match I#0:Rect(minX=0.0,maxX=256.0,minY=-128.0,maxY=128.0)
Q:ShapePair(Rect(minX=0.0,maxX=256.0,minY=-128.0,maxY=128.0) ,
Rect(minX=46.0,maxX=217.0,minY=-114.0,maxY=108.0))
Stack Trace:
java.lang.AssertionError: Shouldn't match
I#0:Rect(minX=0.0,maxX=256.0,minY=-128.0,maxY=128.0)
Q:ShapePair(Rect(minX=0.0,maxX=256.0,minY=-128.0,maxY=128.0) ,
Rect(minX=46.0,maxX=217.0,minY=-114.0,maxY=108.0))
at
__randomizedtesting.SeedInfo.seed([CA75DB0F916D04D4:EFFE54D2DF59BF75]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.fail(SpatialOpRecursivePrefixTreeTest.java:355)
at
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.doTest(SpatialOpRecursivePrefixTreeTest.java:335)
at
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.testContains(SpatialOpRecursivePrefixTreeTest.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1617)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:826)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:862)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359)
at
[jira] [Updated] (LUCENE-5537) Fix version check in TestCheckIndexes
[ https://issues.apache.org/jira/browse/LUCENE-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-5537: -- Attachment: LUCENE-5537.patch Patch: - Moves test to a separate file oal.util.TestConstants - 2 test cases: One just checks that constants LUCENE_VERSION and LUCENE_MAIN_VERSION match, the other test just checks test setup (if ran via ANT) - I removed the ALPHA/BETA handling in those version numbers. This was completely broken. If we have LUCENE 5.0 BETA, we should first decide how to declare LUCENE_MAIN_VERSION for those, to be able to change index format, if not finalized. Fix version check in TestCheckIndexes - Key: LUCENE-5537 URL: https://issues.apache.org/jira/browse/LUCENE-5537 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 4.7 Reporter: Uwe Schindler Assignee: Uwe Schindler Priority: Blocker Fix For: 4.8, 5.0, 4.7.1 Attachments: LUCENE-5537.patch The crazy version check in TestCheckIndexes is broken. Whenever it fails, it requires a horrible amount of understanding: - error messages are useless - you don't know what it really checks and why (no documentation) In addition, we have no clear workflow how to handle version updates: - In 4.6 series we never set the dev.version in common-build to 4.6.1, it always stayed 4.6. The test worked therefore, because the LUCENE_MAIN_VERSION (which is always x.y) was identical - In 4.7 [~steve_rowe] changed the version to the real release version in the branch. The test failed because of this change (LUCENE_MAIN_VERSION was not identical as the dotted bugfix version) We should in any case fix the test: - move it out of TestCheckIndex, it should be in oal.util.TestConstants - Be more verbose on loggin - Remove special cases (leftovers from 4.0-BETA) where we did crazy stuff to make this test pass in alphas and betas. - Only add a check to LUCENE_MAIN_VERSION that it is in format x.y (which is required by Lucene index format), and only check that it is the prefix of the real version as reported by common_build.xml. We should also document and write down when we change the version numbers. I would prefer to use the variant of Lucene 4.6: never change the version number in common-build and override it while building artifacts. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5489) Add query rescoring API
[ https://issues.apache.org/jira/browse/LUCENE-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939053#comment-13939053 ] Robert Muir commented on LUCENE-5489: - +1 to commit this. API is very simple and nice. I tried to think of a better name for the filter, but its private, so its not important. Add query rescoring API --- Key: LUCENE-5489 URL: https://issues.apache.org/jira/browse/LUCENE-5489 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.8, 5.0 Attachments: LUCENE-5489.patch, LUCENE-5489.patch When costly scoring factors are used during searching, a common approach is to do a cheaper / basic query first, collect the top few hundred hits, and then rescore those hits using the more costly query. It's not clear/simple to do this with Lucene today; I think we should make it easier. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.7.0_60-ea-b07) - Build # 9834 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9834/
Java: 64bit/jdk1.7.0_60-ea-b07 -XX:-UseCompressedOops -XX:+UseSerialGC
1 tests failed.
FAILED:
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.testWithin
{#2 seed=[AAE5C2FB97B41223:E3B533A05D29656E]}
Error Message:
Shouldn't match I#0:Rect(minX=-180.0,maxX=180.0,minY=-90.0,maxY=90.0)
Q:ShapePair(Rect(minX=-163.0,maxX=163.0,minY=-90.0,maxY=90.0) ,
Rect(minX=-180.0,maxX=180.0,minY=-90.0,maxY=90.0))
Stack Trace:
java.lang.AssertionError: Shouldn't match
I#0:Rect(minX=-180.0,maxX=180.0,minY=-90.0,maxY=90.0)
Q:ShapePair(Rect(minX=-163.0,maxX=163.0,minY=-90.0,maxY=90.0) ,
Rect(minX=-180.0,maxX=180.0,minY=-90.0,maxY=90.0))
at
__randomizedtesting.SeedInfo.seed([AAE5C2FB97B41223:E3B533A05D29656E]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.fail(SpatialOpRecursivePrefixTreeTest.java:355)
at
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.doTest(SpatialOpRecursivePrefixTreeTest.java:335)
at
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.testWithin(SpatialOpRecursivePrefixTreeTest.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1617)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:826)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:862)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359)
at
[jira] [Commented] (LUCENE-5489) Add query rescoring API
[
https://issues.apache.org/jira/browse/LUCENE-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939069#comment-13939069
]
Simon Willnauer commented on LUCENE-5489:
-
it's awesome that we are adding this. I have almost the same code on a high
level in Elasticsearch and it works just great. Ideally I'd love to drop the
code from ES and replace it with the lucene one but I think we need to iterate
more on this. From what I can see the biggest issues are :
* the way how scores are combined is hardcoded (we just multiply)
* we only have one way to rescore ie. we use another query by default which
would be nice if the interface would allow us to use other ways of rescorers.
* most of the goodies are hidden in a static method I think we should add a
nice interface / abstract class
* it would be awesome if the interface could provide a way to get an
Explanation like other queries...
what I think would make sense is something like this:
{code}
public class AbstractRescorer implements Rescore {
@Override
public TopDocs rescore(IndexSearcher searcher, TopDocs topDocs, int topN) {
// do what is done int he static method
}
protected abstract float combine(float originalScore, float resocredScore);
@Override
public Explanation explain(IndexSearcher searcher, Explanation sourceExplain,
int docId) {
// impl explain
}
}
{code}
I hope this makes sense?
Add query rescoring API
---
Key: LUCENE-5489
URL: https://issues.apache.org/jira/browse/LUCENE-5489
Project: Lucene - Core
Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 4.8, 5.0
Attachments: LUCENE-5489.patch, LUCENE-5489.patch
When costly scoring factors are used during searching, a common
approach is to do a cheaper / basic query first, collect the top few
hundred hits, and then rescore those hits using the more costly
query.
It's not clear/simple to do this with Lucene today; I think we should
make it easier.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5489) Add query rescoring API
[ https://issues.apache.org/jira/browse/LUCENE-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939075#comment-13939075 ] Robert Muir commented on LUCENE-5489: - Can it just be a one method abstract class (essentially the combine)? The patch could even keep the simple method signature of today, implemented via this (which means there is basically a usable example sitting there in the source code, too) Add query rescoring API --- Key: LUCENE-5489 URL: https://issues.apache.org/jira/browse/LUCENE-5489 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.8, 5.0 Attachments: LUCENE-5489.patch, LUCENE-5489.patch When costly scoring factors are used during searching, a common approach is to do a cheaper / basic query first, collect the top few hundred hits, and then rescore those hits using the more costly query. It's not clear/simple to do this with Lucene today; I think we should make it easier. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5489) Add query rescoring API
[ https://issues.apache.org/jira/browse/LUCENE-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939079#comment-13939079 ] Simon Willnauer commented on LUCENE-5489: - I'd be totally ok with skipping the Explain that can be fixed later or in user code. I think as long as I can override the combine it's actually helpful. I think for users the static simple method should remain but I don't think the (non-static) rescore method should be polluted with a Query since that is impl. specifc and can be passed via Ctor args or so but still be hidden if the user uses the simple static API. Add query rescoring API --- Key: LUCENE-5489 URL: https://issues.apache.org/jira/browse/LUCENE-5489 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.8, 5.0 Attachments: LUCENE-5489.patch, LUCENE-5489.patch When costly scoring factors are used during searching, a common approach is to do a cheaper / basic query first, collect the top few hundred hits, and then rescore those hits using the more costly query. It's not clear/simple to do this with Lucene today; I think we should make it easier. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.7.0_51) - Build # 9728 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9728/ Java: 64bit/jdk1.7.0_51 -XX:-UseCompressedOops -XX:+UseParallelGC -XX:-UseSuperWord 1 tests failed. REGRESSION: org.apache.lucene.index.TestIndexWriterExceptions.testNoLostDeletesOrUpdates Error Message: this codec cannot write docvalues Stack Trace: java.lang.UnsupportedOperationException: this codec cannot write docvalues at __randomizedtesting.SeedInfo.seed([E7CE6EAA09B03D88:8EB56C21FF1EF7C8]:0) at org.apache.lucene.codecs.lucene3x.Lucene3xCodec$1.fieldsConsumer(Lucene3xCodec.java:73) at org.apache.lucene.index.DocValuesProcessor.flush(DocValuesProcessor.java:77) at org.apache.lucene.index.TwoStoredFieldsConsumers.flush(TwoStoredFieldsConsumers.java:42) at org.apache.lucene.index.DocFieldProcessor.flush(DocFieldProcessor.java:80) at org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:465) at org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:516) at org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:626) at org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2909) at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3067) at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3034) at org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:320) at org.apache.lucene.index.TestIndexWriterExceptions.testNoLostDeletesOrUpdates(TestIndexWriterExceptions.java:1845) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1617) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:826) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:862) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at
Re: [JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.7.0_51) - Build # 9728 - Still Failing!
Committed a fix. It was a bad svn merge. Shai 2014-03-18 13:24 GMT+02:00 Policeman Jenkins Server jenk...@thetaphi.de: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9728/ Java: 64bit/jdk1.7.0_51 -XX:-UseCompressedOops -XX:+UseParallelGC -XX:-UseSuperWord 1 tests failed. REGRESSION: org.apache.lucene.index.TestIndexWriterExceptions.testNoLostDeletesOrUpdates Error Message: this codec cannot write docvalues Stack Trace: java.lang.UnsupportedOperationException: this codec cannot write docvalues at __randomizedtesting.SeedInfo.seed([E7CE6EAA09B03D88:8EB56C21FF1EF7C8]:0) at org.apache.lucene.codecs.lucene3x.Lucene3xCodec$1.fieldsConsumer(Lucene3xCodec.java:73) at org.apache.lucene.index.DocValuesProcessor.flush(DocValuesProcessor.java:77) at org.apache.lucene.index.TwoStoredFieldsConsumers.flush(TwoStoredFieldsConsumers.java:42) at org.apache.lucene.index.DocFieldProcessor.flush(DocFieldProcessor.java:80) at org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:465) at org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:516) at org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:626) at org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2909) at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3067) at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3034) at org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:320) at org.apache.lucene.index.TestIndexWriterExceptions.testNoLostDeletesOrUpdates(TestIndexWriterExceptions.java:1845) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1617) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:826) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:862) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at
[jira] [Commented] (LUCENE-5513) Binary DocValues Updates
[ https://issues.apache.org/jira/browse/LUCENE-5513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939088#comment-13939088 ] ASF subversion and git services commented on LUCENE-5513: - Commit 1578831 from [~shaie] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1578831 ] LUCENE-5513: fix bad svn merge Binary DocValues Updates Key: LUCENE-5513 URL: https://issues.apache.org/jira/browse/LUCENE-5513 Project: Lucene - Core Issue Type: Wish Components: core/index Reporter: Mikhail Khludnev Assignee: Shai Erera Priority: Minor Fix For: 4.8, 5.0 Attachments: LUCENE-5513.patch, LUCENE-5513.patch, LUCENE-5513.patch, LUCENE-5513.patch LUCENE-5189 was a great move toward. I wish to continue. The reason for having this feature is to have join-index - to write children docnums into parent's binaryDV. I can try to proceed the implementation, but I'm not so experienced in such deep Lucene internals. [~shaie], any hint to begin with is much appreciated. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5537) Fix version check in TestCheckIndexes
[ https://issues.apache.org/jira/browse/LUCENE-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939112#comment-13939112 ] Robert Muir commented on LUCENE-5537: - I don't think we should remove the alpha/beta handling: the scenario we used for 4.0 worked plenty well (you can go back to the mailing list, if oyu want to remember how LUCENE_MAIN_VERSION and the index format were handled). I spent a ton of time on shit like this, i dont think it should be erased just because someone broke the build today. Fix version check in TestCheckIndexes - Key: LUCENE-5537 URL: https://issues.apache.org/jira/browse/LUCENE-5537 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 4.7 Reporter: Uwe Schindler Assignee: Uwe Schindler Priority: Blocker Fix For: 4.8, 5.0, 4.7.1 Attachments: LUCENE-5537.patch The crazy version check in TestCheckIndexes is broken. Whenever it fails, it requires a horrible amount of understanding: - error messages are useless - you don't know what it really checks and why (no documentation) In addition, we have no clear workflow how to handle version updates: - In 4.6 series we never set the dev.version in common-build to 4.6.1, it always stayed 4.6. The test worked therefore, because the LUCENE_MAIN_VERSION (which is always x.y) was identical - In 4.7 [~steve_rowe] changed the version to the real release version in the branch. The test failed because of this change (LUCENE_MAIN_VERSION was not identical as the dotted bugfix version) We should in any case fix the test: - move it out of TestCheckIndex, it should be in oal.util.TestConstants - Be more verbose on loggin - Remove special cases (leftovers from 4.0-BETA) where we did crazy stuff to make this test pass in alphas and betas. - Only add a check to LUCENE_MAIN_VERSION that it is in format x.y (which is required by Lucene index format), and only check that it is the prefix of the real version as reported by common_build.xml. We should also document and write down when we change the version numbers. I would prefer to use the variant of Lucene 4.6: never change the version number in common-build and override it while building artifacts. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_51) - Build # 9725 - Still Failing!
I'll look into this one and get it fixed ASAP.
On Tue, Mar 18, 2014 at 2:26 AM, Policeman Jenkins Server
jenk...@thetaphi.de wrote:
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9725/
Java: 32bit/jdk1.7.0_51 -server -XX:+UseSerialGC
2 tests failed.
FAILED:
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.testContains
{#7 seed=[175A10038A619363:146B27D88CDE16A]}
Error Message:
Shouldn't match I#0:Rect(minX=-180.0,maxX=180.0,minY=-90.0,maxY=90.0)
Q:ShapePair(Rect(minX=-180.0,maxX=180.0,minY=-90.0,maxY=90.0) ,
Rect(minX=-21.0,maxX=-14.0,minY=-26.0,maxY=-21.0))
Stack Trace:
java.lang.AssertionError: Shouldn't match
I#0:Rect(minX=-180.0,maxX=180.0,minY=-90.0,maxY=90.0)
Q:ShapePair(Rect(minX=-180.0,maxX=180.0,minY=-90.0,maxY=90.0) ,
Rect(minX=-21.0,maxX=-14.0,minY=-26.0,maxY=-21.0))
at
__randomizedtesting.SeedInfo.seed([175A10038A619363:146B27D88CDE16A]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.fail(SpatialOpRecursivePrefixTreeTest.java:355)
at
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.doTest(SpatialOpRecursivePrefixTreeTest.java:335)
at
org.apache.lucene.spatial.prefix.SpatialOpRecursivePrefixTreeTest.testContains(SpatialOpRecursivePrefixTreeTest.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1617)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:826)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:862)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at
[jira] [Commented] (LUCENE-5537) Fix version check in TestCheckIndexes
[ https://issues.apache.org/jira/browse/LUCENE-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939119#comment-13939119 ] Uwe Schindler commented on LUCENE-5537: --- Hi Robert, I agree with that on trunk. But in the stable branch we should ensure with the regex, that the MAIN_VERSIOn is x.y, so we prevent anybody doing releases to put 4.7.1 into the LUCENE_MAIN_VERSION. In trunk we can have the stuff with 5.0.*0*.x for alpha beta (the code checks if 3rd part is 0 to detect BETA. But in stable releases we should prevent that. So I can preserve your check in trunk, in 4.x I enforce x.y. Is this fine for you? You agree that cleaning that up and especially adding a more detailed comment about how to handle BETA versions would be ok? If not, please take this issue and do the cleanup yourself. All this shit with startWith and so on is un-understandable. I just cleaned it up and it took me also half a day to test this with all branches and version comibantions, not counted the time to understand that stuff (without a good comment). Steve did not break the build, the build was broken by me in my last commit. It was just not detected in 4.6.1, because we did not change common-build. Fix version check in TestCheckIndexes - Key: LUCENE-5537 URL: https://issues.apache.org/jira/browse/LUCENE-5537 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 4.7 Reporter: Uwe Schindler Assignee: Uwe Schindler Priority: Blocker Fix For: 4.8, 5.0, 4.7.1 Attachments: LUCENE-5537.patch The crazy version check in TestCheckIndexes is broken. Whenever it fails, it requires a horrible amount of understanding: - error messages are useless - you don't know what it really checks and why (no documentation) In addition, we have no clear workflow how to handle version updates: - In 4.6 series we never set the dev.version in common-build to 4.6.1, it always stayed 4.6. The test worked therefore, because the LUCENE_MAIN_VERSION (which is always x.y) was identical - In 4.7 [~steve_rowe] changed the version to the real release version in the branch. The test failed because of this change (LUCENE_MAIN_VERSION was not identical as the dotted bugfix version) We should in any case fix the test: - move it out of TestCheckIndex, it should be in oal.util.TestConstants - Be more verbose on loggin - Remove special cases (leftovers from 4.0-BETA) where we did crazy stuff to make this test pass in alphas and betas. - Only add a check to LUCENE_MAIN_VERSION that it is in format x.y (which is required by Lucene index format), and only check that it is the prefix of the real version as reported by common_build.xml. We should also document and write down when we change the version numbers. I would prefer to use the variant of Lucene 4.6: never change the version number in common-build and override it while building artifacts. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1604) Wildcards, ORs etc inside Phrase Queries
[ https://issues.apache.org/jira/browse/SOLR-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939131#comment-13939131 ] Ahmet Arslan commented on SOLR-1604: Hi [~Anonymous], there is no difference between 4.7.0 and 4.2.1. Committed one has local param addition. You can set inOrder parameter using http://wiki.apache.org/solr/LocalParams And yes hello world h* is perfectly fine. Wildcards, ORs etc inside Phrase Queries Key: SOLR-1604 URL: https://issues.apache.org/jira/browse/SOLR-1604 Project: Solr Issue Type: Improvement Components: query parsers, search Affects Versions: 1.4 Reporter: Ahmet Arslan Assignee: Erick Erickson Priority: Minor Fix For: 4.8, 5.0 Attachments: ASF.LICENSE.NOT.GRANTED--ComplexPhrase.zip, ComplexPhrase-4.2.1.zip, ComplexPhrase-4.7.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhraseQueryParser.java, ComplexPhrase_solr_3.4.zip, SOLR-1604-alternative.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR1604.patch Solr Plugin for ComplexPhraseQueryParser (LUCENE-1486) which supports wildcards, ORs, ranges, fuzzies inside phrase queries. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Reducing the number of warnings in the codebase
On 3/16/2014 2:48 PM, Uwe Schindler wrote: I would prefer: Before we fix warnings by 3rd party tools like Eclipse, we should first fix only the warnings emitted by Javac. The others are just unimportant to me and I don't want to fix those which are just wrong for our code style. Additional followup: With help from Steve Rowe via IRC, I got -Werror working with the ant build. Although some of the warnings I found were straightforward to eliminate, I quickly got myself into trouble when trying to fix the raw usage of Map that is all over ValueSource and its descendants. It seems that these classes cannot be restricted to specific K or V types, at least not as they are written now. Do we just suppress them? I'd like to treat it as a bug, but I'm guessing that the vague Map usage was completely intentional. On switch case fall-through: Some of them can be fixed with break statements, but a number of them are intentional. Is there a way to get the compiler to suppress the warning? I couldn't see one. Various IDEs have comment annotations that will cause the warnings to be ignored within the IDE, but there are no standards. On the IDE side, specifically for eclipse: Ignoring 'usage of a raw type' problems removes 3006 warnings -- nearly half of them. I think a large percentage of these should be fixed, and those that truly cannot be changed should be ignored with SuppressWarnings. I don't think we should actually disable this warning, for two reasons: 1) This also appears to be flagged as a warning by the compiler. 2) Properly using parameters can reveal hidden problems as errors at compile time. Long-term, I would actually go further with this -- use parameters on more of our own classes. Ignoring 'missing serialVersionUID' removes 198 warnings. We should do this. Checking the 'ignore unavoidable generic type problems' box removes 426 warnings. What exactly this might mean is not clear to me, but we should probably do this. Below are the results of some experimentation with Errors/Warnings in eclipse. I didn't try all of the options I found. Disabling deprecation warning: removes 853 warnings 'Comparing identical values' to error: adds 1 error 'Assignment has no effect' to error: adds 5 errors 'Possible accidental boolean assignment' to error: adds 4 errors 'redundant type arguments' (needs diamond) to error: adds 21 errors 'switch missing default case' to error: adds 267 errors 'switch case fallthrough' to error: adds 79 errors 'incomplete switch cases on enum' to error (but not if default present): adds 24 errors 'dead code' to error: adds 58 errors Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1604) Wildcards, ORs etc inside Phrase Queries
[ https://issues.apache.org/jira/browse/SOLR-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939139#comment-13939139 ] Anonymous commented on SOLR-1604: - Thanks Ahmet, Yeah I saw that using debugQuery On and found that even phrase query is executed using Spannear query the addition of wildcard makes it to use spanOR inside spannear query. One more Question: when spannear is given multiple words like spannear(hello,world,hello) with slop 0 how it is working inside to find all the documents containing all above terms adjacent to eachother? Wildcards, ORs etc inside Phrase Queries Key: SOLR-1604 URL: https://issues.apache.org/jira/browse/SOLR-1604 Project: Solr Issue Type: Improvement Components: query parsers, search Affects Versions: 1.4 Reporter: Ahmet Arslan Assignee: Erick Erickson Priority: Minor Fix For: 4.8, 5.0 Attachments: ASF.LICENSE.NOT.GRANTED--ComplexPhrase.zip, ComplexPhrase-4.2.1.zip, ComplexPhrase-4.7.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhraseQueryParser.java, ComplexPhrase_solr_3.4.zip, SOLR-1604-alternative.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR1604.patch Solr Plugin for ComplexPhraseQueryParser (LUCENE-1486) which supports wildcards, ORs, ranges, fuzzies inside phrase queries. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5749) Implement an Overseer status API
[ https://issues.apache.org/jira/browse/SOLR-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-5749: Attachment: SOLR-5749.patch * Track stats per-minute instead of per-second * Added collection processor statistics as well Implement an Overseer status API Key: SOLR-5749 URL: https://issues.apache.org/jira/browse/SOLR-5749 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Shalin Shekhar Mangar Fix For: 5.0 Attachments: SOLR-5749.patch, SOLR-5749.patch Right now there is little to no information exposed about the overseer from SolrCloud. I propose that we have an API for overseer status which can return: # Past N commands executed (grouped by command type) # Status (queue-size, current overseer leader node) # Overseer log -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5537) Fix version check in TestCheckIndexes
[ https://issues.apache.org/jira/browse/LUCENE-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-5537: -- Attachment: LUCENE-5537.patch Patch including alpha beta checks. I hardened the whole thing, so we ensure: LUCENE_MAIN_VERSION is x.y or x.y.0.z, all other version numbers are refused. Is this OK for you, Robert. I also added documentation, so we have a documented pattern for alpha/beta versions. Fix version check in TestCheckIndexes - Key: LUCENE-5537 URL: https://issues.apache.org/jira/browse/LUCENE-5537 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 4.7 Reporter: Uwe Schindler Assignee: Uwe Schindler Priority: Blocker Fix For: 4.8, 5.0, 4.7.1 Attachments: LUCENE-5537.patch, LUCENE-5537.patch The crazy version check in TestCheckIndexes is broken. Whenever it fails, it requires a horrible amount of understanding: - error messages are useless - you don't know what it really checks and why (no documentation) In addition, we have no clear workflow how to handle version updates: - In 4.6 series we never set the dev.version in common-build to 4.6.1, it always stayed 4.6. The test worked therefore, because the LUCENE_MAIN_VERSION (which is always x.y) was identical - In 4.7 [~steve_rowe] changed the version to the real release version in the branch. The test failed because of this change (LUCENE_MAIN_VERSION was not identical as the dotted bugfix version) We should in any case fix the test: - move it out of TestCheckIndex, it should be in oal.util.TestConstants - Be more verbose on loggin - Remove special cases (leftovers from 4.0-BETA) where we did crazy stuff to make this test pass in alphas and betas. - Only add a check to LUCENE_MAIN_VERSION that it is in format x.y (which is required by Lucene index format), and only check that it is the prefix of the real version as reported by common_build.xml. We should also document and write down when we change the version numbers. I would prefer to use the variant of Lucene 4.6: never change the version number in common-build and override it while building artifacts. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5537) Fix version check in TestCheckIndexes
[ https://issues.apache.org/jira/browse/LUCENE-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939154#comment-13939154 ] Robert Muir commented on LUCENE-5537: - thank you Uwe. +1 Fix version check in TestCheckIndexes - Key: LUCENE-5537 URL: https://issues.apache.org/jira/browse/LUCENE-5537 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 4.7 Reporter: Uwe Schindler Assignee: Uwe Schindler Priority: Blocker Fix For: 4.8, 5.0, 4.7.1 Attachments: LUCENE-5537.patch, LUCENE-5537.patch The crazy version check in TestCheckIndexes is broken. Whenever it fails, it requires a horrible amount of understanding: - error messages are useless - you don't know what it really checks and why (no documentation) In addition, we have no clear workflow how to handle version updates: - In 4.6 series we never set the dev.version in common-build to 4.6.1, it always stayed 4.6. The test worked therefore, because the LUCENE_MAIN_VERSION (which is always x.y) was identical - In 4.7 [~steve_rowe] changed the version to the real release version in the branch. The test failed because of this change (LUCENE_MAIN_VERSION was not identical as the dotted bugfix version) We should in any case fix the test: - move it out of TestCheckIndex, it should be in oal.util.TestConstants - Be more verbose on loggin - Remove special cases (leftovers from 4.0-BETA) where we did crazy stuff to make this test pass in alphas and betas. - Only add a check to LUCENE_MAIN_VERSION that it is in format x.y (which is required by Lucene index format), and only check that it is the prefix of the real version as reported by common_build.xml. We should also document and write down when we change the version numbers. I would prefer to use the variant of Lucene 4.6: never change the version number in common-build and override it while building artifacts. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Reducing the number of warnings in the codebase
On switch case fall-through: Some of them can be fixed with break statements, but a number of them are intentional. Is there a way to get the compiler to suppress the warning? I couldn't see one. Various IDEs have comment annotations that will cause the warnings to be ignored within the IDE, but there are no standards. @SuppressWarnings(fallthrough) is the official one supported by javac and eclipse. Uwe - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5529) Spatial: Small optimization searching on indexed non-point shapes
[ https://issues.apache.org/jira/browse/LUCENE-5529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939186#comment-13939186 ] ASF subversion and git services commented on LUCENE-5529: - Commit 1578868 from [~dsmiley] in branch 'dev/trunk' [ https://svn.apache.org/r1578868 ] LUCENE-5529: Spatial RPT optimization to skip intersection test on redundant cells. Other small changes too. Spatial: Small optimization searching on indexed non-point shapes - Key: LUCENE-5529 URL: https://issues.apache.org/jira/browse/LUCENE-5529 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Priority: Minor Fix For: 4.8 Attachments: LUCENE-5529_Skip_redundant_non-point_scanned_cells.patch When searching for indexed non-point shapes (such as polygons), there are redundant cells which can be skipped at the bottom detail level of the search. This won't be a problem once LUCENE-4942 is fixed since there then won't be any but it's easy to fix now. This affects all predicates RecursivePrefixTreeStrategy uses except Contains. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5529) Spatial: Small optimization searching on indexed non-point shapes
[ https://issues.apache.org/jira/browse/LUCENE-5529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939188#comment-13939188 ] ASF subversion and git services commented on LUCENE-5529: - Commit 1578871 from [~dsmiley] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1578871 ] LUCENE-5529: Spatial RPT optimization to skip intersection test on redundant cells. Other small changes too. Spatial: Small optimization searching on indexed non-point shapes - Key: LUCENE-5529 URL: https://issues.apache.org/jira/browse/LUCENE-5529 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Priority: Minor Fix For: 4.8 Attachments: LUCENE-5529_Skip_redundant_non-point_scanned_cells.patch When searching for indexed non-point shapes (such as polygons), there are redundant cells which can be skipped at the bottom detail level of the search. This won't be a problem once LUCENE-4942 is fixed since there then won't be any but it's easy to fix now. This affects all predicates RecursivePrefixTreeStrategy uses except Contains. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5529) Spatial: Small optimization searching on indexed non-point shapes
[ https://issues.apache.org/jira/browse/LUCENE-5529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved LUCENE-5529. -- Resolution: Fixed Spatial: Small optimization searching on indexed non-point shapes - Key: LUCENE-5529 URL: https://issues.apache.org/jira/browse/LUCENE-5529 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Priority: Minor Fix For: 4.8 Attachments: LUCENE-5529_Skip_redundant_non-point_scanned_cells.patch When searching for indexed non-point shapes (such as polygons), there are redundant cells which can be skipped at the bottom detail level of the search. This won't be a problem once LUCENE-4942 is fixed since there then won't be any but it's easy to fix now. This affects all predicates RecursivePrefixTreeStrategy uses except Contains. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5537) Fix version check in TestCheckIndexes
[ https://issues.apache.org/jira/browse/LUCENE-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-5537: -- Attachment: LUCENE-5537.patch I improved the test a bit, I think now it is ready to commit: - removed obsolete test - relaxed the startsWith part of the verson property to only search for common prefix, not explicit startsWith. We have to do this, because our test cases are running against a non-jar classpath, so we have no manifest file with version numbers. Unfortunately: Because we don't run test with a real JAR file, we have no manifest, so we would not detect all problems. To ensure also the version constants from a real lucene-core.jar file are OK, we would need to test against one. I will commit and backport this in a minute (to fix 4.7 builds). Fix version check in TestCheckIndexes - Key: LUCENE-5537 URL: https://issues.apache.org/jira/browse/LUCENE-5537 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 4.7 Reporter: Uwe Schindler Assignee: Uwe Schindler Priority: Blocker Fix For: 4.8, 5.0, 4.7.1 Attachments: LUCENE-5537.patch, LUCENE-5537.patch, LUCENE-5537.patch The crazy version check in TestCheckIndexes is broken. Whenever it fails, it requires a horrible amount of understanding: - error messages are useless - you don't know what it really checks and why (no documentation) In addition, we have no clear workflow how to handle version updates: - In 4.6 series we never set the dev.version in common-build to 4.6.1, it always stayed 4.6. The test worked therefore, because the LUCENE_MAIN_VERSION (which is always x.y) was identical - In 4.7 [~steve_rowe] changed the version to the real release version in the branch. The test failed because of this change (LUCENE_MAIN_VERSION was not identical as the dotted bugfix version) We should in any case fix the test: - move it out of TestCheckIndex, it should be in oal.util.TestConstants - Be more verbose on loggin - Remove special cases (leftovers from 4.0-BETA) where we did crazy stuff to make this test pass in alphas and betas. - Only add a check to LUCENE_MAIN_VERSION that it is in format x.y (which is required by Lucene index format), and only check that it is the prefix of the real version as reported by common_build.xml. We should also document and write down when we change the version numbers. I would prefer to use the variant of Lucene 4.6: never change the version number in common-build and override it while building artifacts. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1604) Wildcards, ORs etc inside Phrase Queries
[ https://issues.apache.org/jira/browse/SOLR-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939198#comment-13939198 ] Ahmet Arslan commented on SOLR-1604: bq. when spannear is given multiple words like spannear(hello,world,hello) with slop 0 With inOrder=true or inOrder=false? I am sure what happens, when you use the same term twice. I remember someone asked similar question on lucene list. http://search-lucene.com/m/SnDCWotpUB1 Span*Query family less used so there can be gotchas. Can you please tell us this treat is related your use case? Wildcards, ORs etc inside Phrase Queries Key: SOLR-1604 URL: https://issues.apache.org/jira/browse/SOLR-1604 Project: Solr Issue Type: Improvement Components: query parsers, search Affects Versions: 1.4 Reporter: Ahmet Arslan Assignee: Erick Erickson Priority: Minor Fix For: 4.8, 5.0 Attachments: ASF.LICENSE.NOT.GRANTED--ComplexPhrase.zip, ComplexPhrase-4.2.1.zip, ComplexPhrase-4.7.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhraseQueryParser.java, ComplexPhrase_solr_3.4.zip, SOLR-1604-alternative.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR1604.patch Solr Plugin for ComplexPhraseQueryParser (LUCENE-1486) which supports wildcards, ORs, ranges, fuzzies inside phrase queries. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4978) Spatial search with point query won't find identical indexed point
[ https://issues.apache.org/jira/browse/LUCENE-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939203#comment-13939203 ] ASF subversion and git services commented on LUCENE-4978: - Commit 1578891 from [~dsmiley] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1578891 ] LUCENE-4978: invert biasContains on query side Spatial search with point query won't find identical indexed point -- Key: LUCENE-4978 URL: https://issues.apache.org/jira/browse/LUCENE-4978 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Affects Versions: 4.1 Reporter: David Smiley Assignee: David Smiley Priority: Minor Fix For: 4.8 Attachments: LUCENE-4978_fix_small_grid_false_negatives.patch Given a document with indexed POINT (10 20), when a search for INTERSECTS( POINT (10 20)) is issued, no results are returned. The work-around is to not search with a point shape, use a very small-radius circle or rectangle. (I'm marking this issue as minor because it's easy to do this). An unstated objective of the PrefixTree/grid approximation is that no matter what precision you use, an intersects query will find all true-positives. Due to approximations, it may also find some close false-positives. But in the case above, that unstated promise is violated. But it can also happen for query shapes other than points which do in fact barely enclose the point given at index time yet the indexed point is in-effect shifted to the center point of a cell which could be outside the query shape, and ultimately leading to a false-negative. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4978) Spatial search with point query won't find identical indexed point
[ https://issues.apache.org/jira/browse/LUCENE-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939202#comment-13939202 ] ASF subversion and git services commented on LUCENE-4978: - Commit 1578889 from [~dsmiley] in branch 'dev/trunk' [ https://svn.apache.org/r1578889 ] LUCENE-4978: invert biasContains on query side Spatial search with point query won't find identical indexed point -- Key: LUCENE-4978 URL: https://issues.apache.org/jira/browse/LUCENE-4978 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Affects Versions: 4.1 Reporter: David Smiley Assignee: David Smiley Priority: Minor Fix For: 4.8 Attachments: LUCENE-4978_fix_small_grid_false_negatives.patch Given a document with indexed POINT (10 20), when a search for INTERSECTS( POINT (10 20)) is issued, no results are returned. The work-around is to not search with a point shape, use a very small-radius circle or rectangle. (I'm marking this issue as minor because it's easy to do this). An unstated objective of the PrefixTree/grid approximation is that no matter what precision you use, an intersects query will find all true-positives. Due to approximations, it may also find some close false-positives. But in the case above, that unstated promise is violated. But it can also happen for query shapes other than points which do in fact barely enclose the point given at index time yet the indexed point is in-effect shifted to the center point of a cell which could be outside the query shape, and ultimately leading to a false-negative. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.7-Linux (32bit/jdk1.8.0-fcs-b132) - Build # 3 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.7-Linux/3/ Java: 32bit/jdk1.8.0-fcs-b132 -client -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.lucene.index.TestCheckIndex.testLuceneConstantVersion Error Message: Invalid version: 4.7.1 Stack Trace: java.lang.AssertionError: Invalid version: 4.7.1 at __randomizedtesting.SeedInfo.seed([1B5CA1A1AF9FEEB8:D8C2566F89800E77]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.lucene.index.TestCheckIndex.testLuceneConstantVersion(TestCheckIndex.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:744) Build Log: [...truncated 177 lines...] [junit4] Suite: org.apache.lucene.index.TestCheckIndex [junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestCheckIndex -Dtests.method=testLuceneConstantVersion -Dtests.seed=1B5CA1A1AF9FEEB8 -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=en_PH -Dtests.timezone=America/Los_Angeles -Dtests.file.encoding=ISO-8859-1 [junit4] FAILURE 0.15s J1 | TestCheckIndex.testLuceneConstantVersion [junit4] Throwable #1: java.lang.AssertionError: Invalid
[jira] [Updated] (LUCENE-5537) Fix version check in TestCheckIndexes
[
https://issues.apache.org/jira/browse/LUCENE-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-5537:
--
Attachment: LUCENE-5537.patch
I added another sanity check: The last LUCENE_XY constant must be returned when
parsing the LUCENE_MAIN_VERSION constant.
When looking at this, I found out that we have a problem with
{{Version.LUCENE_XY}} constants after Lucene 4.9! :-) The parser cannot handle
this (e.g. 4.10 cannot be converted to {{LUCENE_XY}}), but also the possible
constant looks wrong: {{LUCENE_410}} - really?
Nevertheless it is now ready to commit. The 4.10 problems can be handled later,
I have no idea how we should do this.
Fix version check in TestCheckIndexes
-
Key: LUCENE-5537
URL: https://issues.apache.org/jira/browse/LUCENE-5537
Project: Lucene - Core
Issue Type: Bug
Components: core/other
Affects Versions: 4.7
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Priority: Blocker
Fix For: 4.8, 5.0, 4.7.1
Attachments: LUCENE-5537.patch, LUCENE-5537.patch, LUCENE-5537.patch,
LUCENE-5537.patch
The crazy version check in TestCheckIndexes is broken. Whenever it fails, it
requires a horrible amount of understanding:
- error messages are useless
- you don't know what it really checks and why (no documentation)
In addition, we have no clear workflow how to handle version updates:
- In 4.6 series we never set the dev.version in common-build to 4.6.1, it
always stayed 4.6. The test worked therefore, because the LUCENE_MAIN_VERSION
(which is always x.y) was identical
- In 4.7 [~steve_rowe] changed the version to the real release version in the
branch. The test failed because of this change (LUCENE_MAIN_VERSION was not
identical as the dotted bugfix version)
We should in any case fix the test:
- move it out of TestCheckIndex, it should be in oal.util.TestConstants
- Be more verbose on loggin
- Remove special cases (leftovers from 4.0-BETA) where we did crazy stuff to
make this test pass in alphas and betas.
- Only add a check to LUCENE_MAIN_VERSION that it is in format x.y (which
is required by Lucene index format), and only check that it is the prefix of
the real version as reported by common_build.xml.
We should also document and write down when we change the version numbers. I
would prefer to use the variant of Lucene 4.6: never change the version
number in common-build and override it while building artifacts.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5537) Fix version check in TestCheckIndexes
[ https://issues.apache.org/jira/browse/LUCENE-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939250#comment-13939250 ] Steve Rowe commented on LUCENE-5537: bq. I will commit and backport this in a minute (to fix 4.7 builds). I ran the lucene-core tests on lucene_solr_4_7 with the latest patch, and all succeeded. Thanks Uwe. Fix version check in TestCheckIndexes - Key: LUCENE-5537 URL: https://issues.apache.org/jira/browse/LUCENE-5537 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 4.7 Reporter: Uwe Schindler Assignee: Uwe Schindler Priority: Blocker Fix For: 4.8, 5.0, 4.7.1 Attachments: LUCENE-5537.patch, LUCENE-5537.patch, LUCENE-5537.patch, LUCENE-5537.patch The crazy version check in TestCheckIndexes is broken. Whenever it fails, it requires a horrible amount of understanding: - error messages are useless - you don't know what it really checks and why (no documentation) In addition, we have no clear workflow how to handle version updates: - In 4.6 series we never set the dev.version in common-build to 4.6.1, it always stayed 4.6. The test worked therefore, because the LUCENE_MAIN_VERSION (which is always x.y) was identical - In 4.7 [~steve_rowe] changed the version to the real release version in the branch. The test failed because of this change (LUCENE_MAIN_VERSION was not identical as the dotted bugfix version) We should in any case fix the test: - move it out of TestCheckIndex, it should be in oal.util.TestConstants - Be more verbose on loggin - Remove special cases (leftovers from 4.0-BETA) where we did crazy stuff to make this test pass in alphas and betas. - Only add a check to LUCENE_MAIN_VERSION that it is in format x.y (which is required by Lucene index format), and only check that it is the prefix of the real version as reported by common_build.xml. We should also document and write down when we change the version numbers. I would prefer to use the variant of Lucene 4.6: never change the version number in common-build and override it while building artifacts. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5537) Fix version check in TestCheckIndexes
[ https://issues.apache.org/jira/browse/LUCENE-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939252#comment-13939252 ] Steve Rowe commented on LUCENE-5537: bq. Nevertheless it is now ready to commit. The 4.10 problems can be handled later, I have no idea how we should do this. Hexadecimal? :) Fix version check in TestCheckIndexes - Key: LUCENE-5537 URL: https://issues.apache.org/jira/browse/LUCENE-5537 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 4.7 Reporter: Uwe Schindler Assignee: Uwe Schindler Priority: Blocker Fix For: 4.8, 5.0, 4.7.1 Attachments: LUCENE-5537.patch, LUCENE-5537.patch, LUCENE-5537.patch, LUCENE-5537.patch The crazy version check in TestCheckIndexes is broken. Whenever it fails, it requires a horrible amount of understanding: - error messages are useless - you don't know what it really checks and why (no documentation) In addition, we have no clear workflow how to handle version updates: - In 4.6 series we never set the dev.version in common-build to 4.6.1, it always stayed 4.6. The test worked therefore, because the LUCENE_MAIN_VERSION (which is always x.y) was identical - In 4.7 [~steve_rowe] changed the version to the real release version in the branch. The test failed because of this change (LUCENE_MAIN_VERSION was not identical as the dotted bugfix version) We should in any case fix the test: - move it out of TestCheckIndex, it should be in oal.util.TestConstants - Be more verbose on loggin - Remove special cases (leftovers from 4.0-BETA) where we did crazy stuff to make this test pass in alphas and betas. - Only add a check to LUCENE_MAIN_VERSION that it is in format x.y (which is required by Lucene index format), and only check that it is the prefix of the real version as reported by common_build.xml. We should also document and write down when we change the version numbers. I would prefer to use the variant of Lucene 4.6: never change the version number in common-build and override it while building artifacts. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5111) Fix WordDelimiterFilter
[ https://issues.apache.org/jira/browse/LUCENE-5111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5111: Attachment: LUCENE-5111.patch I cleaned it up, beefed up tests, and added backwards compatibility (in case for some reason someone depends on the old behavior for some reason). I think its ready, would like to bake in trunk in case TestRandomChains finds some surprises. Fix WordDelimiterFilter --- Key: LUCENE-5111 URL: https://issues.apache.org/jira/browse/LUCENE-5111 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Assignee: Adrien Grand Attachments: LUCENE-5111.patch, LUCENE-5111.patch WordDelimiterFilter is documented as broken is TestRandomChains (LUCENE-4641). Given how used it is, we should try to fix it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-MAVEN] Lucene-Solr-Maven-4.x #615: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/615/ 1 tests failed. REGRESSION: org.apache.solr.cloud.OverseerTest.testOverseerFailure Error Message: Could not register as the leader because creating the ephemeral registration node in ZooKeeper failed Stack Trace: org.apache.solr.common.SolrException: Could not register as the leader because creating the ephemeral registration node in ZooKeeper failed at org.apache.zookeeper.KeeperException.create(KeeperException.java:119) at org.apache.zookeeper.KeeperException.create(KeeperException.java:51) at org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:783) at org.apache.solr.common.cloud.SolrZkClient$10.execute(SolrZkClient.java:431) at org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:73) at org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:428) at org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:385) at org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:372) at org.apache.solr.cloud.ShardLeaderElectionContextBase$1.execute(ElectionContext.java:127) at org.apache.solr.common.util.RetryUtil.retryOnThrowable(RetryUtil.java:34) at org.apache.solr.cloud.ShardLeaderElectionContextBase.runLeaderProcess(ElectionContext.java:122) at org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:164) at org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:108) at org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:156) at org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:289) at org.apache.solr.cloud.OverseerTest$MockZKController.publishState(OverseerTest.java:155) at org.apache.solr.cloud.OverseerTest.testOverseerFailure(OverseerTest.java:666) Build Log: [...truncated 53539 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/build.xml:490: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/build.xml:182: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-4.x/extra-targets.xml:77: Java returned: 1 Total time: 148 minutes 25 seconds Build step 'Invoke Ant' marked build as failure Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5537) Fix version check in TestCheckIndexes
[ https://issues.apache.org/jira/browse/LUCENE-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939290#comment-13939290 ] ASF subversion and git services commented on LUCENE-5537: - Commit 1578930 from [~thetaphi] in branch 'dev/trunk' [ https://svn.apache.org/r1578930 ] LUCENE-5537: Fix version checks in TestCheckIndex - TestConstants Fix version check in TestCheckIndexes - Key: LUCENE-5537 URL: https://issues.apache.org/jira/browse/LUCENE-5537 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 4.7 Reporter: Uwe Schindler Assignee: Uwe Schindler Priority: Blocker Fix For: 4.8, 5.0, 4.7.1 Attachments: LUCENE-5537.patch, LUCENE-5537.patch, LUCENE-5537.patch, LUCENE-5537.patch The crazy version check in TestCheckIndexes is broken. Whenever it fails, it requires a horrible amount of understanding: - error messages are useless - you don't know what it really checks and why (no documentation) In addition, we have no clear workflow how to handle version updates: - In 4.6 series we never set the dev.version in common-build to 4.6.1, it always stayed 4.6. The test worked therefore, because the LUCENE_MAIN_VERSION (which is always x.y) was identical - In 4.7 [~steve_rowe] changed the version to the real release version in the branch. The test failed because of this change (LUCENE_MAIN_VERSION was not identical as the dotted bugfix version) We should in any case fix the test: - move it out of TestCheckIndex, it should be in oal.util.TestConstants - Be more verbose on loggin - Remove special cases (leftovers from 4.0-BETA) where we did crazy stuff to make this test pass in alphas and betas. - Only add a check to LUCENE_MAIN_VERSION that it is in format x.y (which is required by Lucene index format), and only check that it is the prefix of the real version as reported by common_build.xml. We should also document and write down when we change the version numbers. I would prefer to use the variant of Lucene 4.6: never change the version number in common-build and override it while building artifacts. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5537) Fix version check in TestCheckIndexes
[ https://issues.apache.org/jira/browse/LUCENE-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939301#comment-13939301 ] ASF subversion and git services commented on LUCENE-5537: - Commit 1578932 from [~thetaphi] in branch 'dev/trunk' [ https://svn.apache.org/r1578932 ] LUCENE-5537: During tests use real version, not dev.version. We should nuke dev.version, it is no longer used anywhere! Fix version check in TestCheckIndexes - Key: LUCENE-5537 URL: https://issues.apache.org/jira/browse/LUCENE-5537 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 4.7 Reporter: Uwe Schindler Assignee: Uwe Schindler Priority: Blocker Fix For: 4.8, 5.0, 4.7.1 Attachments: LUCENE-5537.patch, LUCENE-5537.patch, LUCENE-5537.patch, LUCENE-5537.patch The crazy version check in TestCheckIndexes is broken. Whenever it fails, it requires a horrible amount of understanding: - error messages are useless - you don't know what it really checks and why (no documentation) In addition, we have no clear workflow how to handle version updates: - In 4.6 series we never set the dev.version in common-build to 4.6.1, it always stayed 4.6. The test worked therefore, because the LUCENE_MAIN_VERSION (which is always x.y) was identical - In 4.7 [~steve_rowe] changed the version to the real release version in the branch. The test failed because of this change (LUCENE_MAIN_VERSION was not identical as the dotted bugfix version) We should in any case fix the test: - move it out of TestCheckIndex, it should be in oal.util.TestConstants - Be more verbose on loggin - Remove special cases (leftovers from 4.0-BETA) where we did crazy stuff to make this test pass in alphas and betas. - Only add a check to LUCENE_MAIN_VERSION that it is in format x.y (which is required by Lucene index format), and only check that it is the prefix of the real version as reported by common_build.xml. We should also document and write down when we change the version numbers. I would prefer to use the variant of Lucene 4.6: never change the version number in common-build and override it while building artifacts. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5537) Fix version check in TestCheckIndexes
[ https://issues.apache.org/jira/browse/LUCENE-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939304#comment-13939304 ] ASF subversion and git services commented on LUCENE-5537: - Commit 1578933 from [~thetaphi] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1578933 ] Merged revision(s) 1578930 from lucene/dev/trunk: LUCENE-5537: Fix version checks in TestCheckIndex - TestConstants, use version instead dev.version for tests Fix version check in TestCheckIndexes - Key: LUCENE-5537 URL: https://issues.apache.org/jira/browse/LUCENE-5537 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 4.7 Reporter: Uwe Schindler Assignee: Uwe Schindler Priority: Blocker Fix For: 4.8, 5.0, 4.7.1 Attachments: LUCENE-5537.patch, LUCENE-5537.patch, LUCENE-5537.patch, LUCENE-5537.patch The crazy version check in TestCheckIndexes is broken. Whenever it fails, it requires a horrible amount of understanding: - error messages are useless - you don't know what it really checks and why (no documentation) In addition, we have no clear workflow how to handle version updates: - In 4.6 series we never set the dev.version in common-build to 4.6.1, it always stayed 4.6. The test worked therefore, because the LUCENE_MAIN_VERSION (which is always x.y) was identical - In 4.7 [~steve_rowe] changed the version to the real release version in the branch. The test failed because of this change (LUCENE_MAIN_VERSION was not identical as the dotted bugfix version) We should in any case fix the test: - move it out of TestCheckIndex, it should be in oal.util.TestConstants - Be more verbose on loggin - Remove special cases (leftovers from 4.0-BETA) where we did crazy stuff to make this test pass in alphas and betas. - Only add a check to LUCENE_MAIN_VERSION that it is in format x.y (which is required by Lucene index format), and only check that it is the prefix of the real version as reported by common_build.xml. We should also document and write down when we change the version numbers. I would prefer to use the variant of Lucene 4.6: never change the version number in common-build and override it while building artifacts. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5537) Fix version check in TestCheckIndexes
[ https://issues.apache.org/jira/browse/LUCENE-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939307#comment-13939307 ] ASF subversion and git services commented on LUCENE-5537: - Commit 1578936 from [~thetaphi] in branch 'dev/branches/lucene_solr_4_7' [ https://svn.apache.org/r1578936 ] Merged revision(s) 1578933 from lucene/dev/branches/branch_4x: Merged revision(s) 1578930 from lucene/dev/trunk: LUCENE-5537: Fix version checks in TestCheckIndex - TestConstants, use version instead dev.version for tests Fix version check in TestCheckIndexes - Key: LUCENE-5537 URL: https://issues.apache.org/jira/browse/LUCENE-5537 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 4.7 Reporter: Uwe Schindler Assignee: Uwe Schindler Priority: Blocker Fix For: 4.8, 5.0, 4.7.1 Attachments: LUCENE-5537.patch, LUCENE-5537.patch, LUCENE-5537.patch, LUCENE-5537.patch The crazy version check in TestCheckIndexes is broken. Whenever it fails, it requires a horrible amount of understanding: - error messages are useless - you don't know what it really checks and why (no documentation) In addition, we have no clear workflow how to handle version updates: - In 4.6 series we never set the dev.version in common-build to 4.6.1, it always stayed 4.6. The test worked therefore, because the LUCENE_MAIN_VERSION (which is always x.y) was identical - In 4.7 [~steve_rowe] changed the version to the real release version in the branch. The test failed because of this change (LUCENE_MAIN_VERSION was not identical as the dotted bugfix version) We should in any case fix the test: - move it out of TestCheckIndex, it should be in oal.util.TestConstants - Be more verbose on loggin - Remove special cases (leftovers from 4.0-BETA) where we did crazy stuff to make this test pass in alphas and betas. - Only add a check to LUCENE_MAIN_VERSION that it is in format x.y (which is required by Lucene index format), and only check that it is the prefix of the real version as reported by common_build.xml. We should also document and write down when we change the version numbers. I would prefer to use the variant of Lucene 4.6: never change the version number in common-build and override it while building artifacts. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5537) Fix version check in TestCheckIndexes
[ https://issues.apache.org/jira/browse/LUCENE-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-5537. --- Resolution: Fixed Fix version check in TestCheckIndexes - Key: LUCENE-5537 URL: https://issues.apache.org/jira/browse/LUCENE-5537 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 4.7 Reporter: Uwe Schindler Assignee: Uwe Schindler Priority: Blocker Fix For: 4.8, 5.0, 4.7.1 Attachments: LUCENE-5537.patch, LUCENE-5537.patch, LUCENE-5537.patch, LUCENE-5537.patch The crazy version check in TestCheckIndexes is broken. Whenever it fails, it requires a horrible amount of understanding: - error messages are useless - you don't know what it really checks and why (no documentation) In addition, we have no clear workflow how to handle version updates: - In 4.6 series we never set the dev.version in common-build to 4.6.1, it always stayed 4.6. The test worked therefore, because the LUCENE_MAIN_VERSION (which is always x.y) was identical - In 4.7 [~steve_rowe] changed the version to the real release version in the branch. The test failed because of this change (LUCENE_MAIN_VERSION was not identical as the dotted bugfix version) We should in any case fix the test: - move it out of TestCheckIndex, it should be in oal.util.TestConstants - Be more verbose on loggin - Remove special cases (leftovers from 4.0-BETA) where we did crazy stuff to make this test pass in alphas and betas. - Only add a check to LUCENE_MAIN_VERSION that it is in format x.y (which is required by Lucene index format), and only check that it is the prefix of the real version as reported by common_build.xml. We should also document and write down when we change the version numbers. I would prefer to use the variant of Lucene 4.6: never change the version number in common-build and override it while building artifacts. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5877) allow empty values in EnumField
Elran Dvir created SOLR-5877: Summary: allow empty values in EnumField Key: SOLR-5877 URL: https://issues.apache.org/jira/browse/SOLR-5877 Project: Solr Issue Type: Improvement Reporter: Elran Dvir now This will be possible: enumsConfig !-- note: you cannot change the order/existing values in enum without reindexing. but you can always add new values to the end. -- enum name=severity value/value valueLow/value valueHigh/value valueCritical/value /enum /enumsConfig The patch is attached -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5877) allow empty values in EnumField
[ https://issues.apache.org/jira/browse/SOLR-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elran Dvir updated SOLR-5877: - Attachment: SOLR-5877.patch allow empty values in EnumField --- Key: SOLR-5877 URL: https://issues.apache.org/jira/browse/SOLR-5877 Project: Solr Issue Type: Improvement Reporter: Elran Dvir Attachments: SOLR-5877.patch now This will be possible: enumsConfig !-- note: you cannot change the order/existing values in enum without reindexing. but you can always add new values to the end. -- enum name=severity value/value valueLow/value valueHigh/value valueCritical/value /enum /enumsConfig The patch is attached -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5868) HttpClient should be configured to use ALLOW_ALL_HOSTNAME hostname verifier to simplify SSL setup
[ https://issues.apache.org/jira/browse/SOLR-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939358#comment-13939358 ] Steve Davids commented on SOLR-5868: Would a system property of solr.ssl.checkName or solr.ssl.checkPeerName be acceptable? This is modeled off of mod_ssl http://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslproxycheckpeername. I can update the patch to reflect the changes if this is the route we would like to go. HttpClient should be configured to use ALLOW_ALL_HOSTNAME hostname verifier to simplify SSL setup - Key: SOLR-5868 URL: https://issues.apache.org/jira/browse/SOLR-5868 Project: Solr Issue Type: Improvement Affects Versions: 4.7 Reporter: Steve Davids Assignee: Mark Miller Fix For: 4.8, 5.0, 4.7.1 Attachments: SOLR-5868.patch The default HttpClient hostname verifier is the BROWSER_COMPATIBLE_HOSTNAME_VERIFIER which verifies the hostname that is being connected to matches the hostname presented within the certificate. This is meant to protect clients that are making external requests out across the internet, but requests within the the SOLR cluster should be trusted and can be relaxed to simplify the SSL/certificate setup process. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5536) TaxonomyFacetSumInt/FloatAssociations should not rollup()
[
https://issues.apache.org/jira/browse/LUCENE-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-5536:
---
Attachment: LUCENE-5536.patch
Patch removes the call to rollup(). I checked and the rest is not a problem
today:
* We don't allow setting the association dimensions as hierarchical
* We only encode the exact category's ordinal w/ the associated value, and not
its parents
* We do add all the category's path components as drill-down terms, which is
good. I means you can associate a document with a/b/c=0.4, and still find this
document if a drill-down on a/ is made
So all in all it was just the rollup() call that had to be removed. I plan to
commit this shortly.
TaxonomyFacetSumInt/FloatAssociations should not rollup()
-
Key: LUCENE-5536
URL: https://issues.apache.org/jira/browse/LUCENE-5536
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Reporter: Shai Erera
Attachments: LUCENE-5536.patch
Stumbled upon this by accident when I reviewed the code. The previous
associations impl never rolled-up. The assumption is that association values
are given to exact categories and have no hierarchical meaning. For instance
if a document is associated with two categories: {{Category/CS/Algo}} and
{{Category/CS/DataStructure}} with weights {{0.95}} and {{0.43}}
respectively, it is not associated with {{Category/CS}} with weight {{1.38}}!
:)
If the app wants to association values to apply to parents in the hierarchy
as well, it needs to explicitly specify that (as in passing the hierarchy
categories with their own association value).
I will fix the bug and also make sure the app cannot trip it by accidentally
specifying hierarchical on these categories, or that if it does (cause e.g.
it indexes the categories for both counting and assoc values) then we don't
apply the association to all the categories in the hierarchy.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5536) TaxonomyFacetSumInt/FloatAssociations should not rollup()
[
https://issues.apache.org/jira/browse/LUCENE-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939370#comment-13939370
]
Michael McCandless commented on LUCENE-5536:
I think we should backport to 4.7.1 too, if the train has not left the station?
TaxonomyFacetSumInt/FloatAssociations should not rollup()
-
Key: LUCENE-5536
URL: https://issues.apache.org/jira/browse/LUCENE-5536
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Reporter: Shai Erera
Attachments: LUCENE-5536.patch
Stumbled upon this by accident when I reviewed the code. The previous
associations impl never rolled-up. The assumption is that association values
are given to exact categories and have no hierarchical meaning. For instance
if a document is associated with two categories: {{Category/CS/Algo}} and
{{Category/CS/DataStructure}} with weights {{0.95}} and {{0.43}}
respectively, it is not associated with {{Category/CS}} with weight {{1.38}}!
:)
If the app wants to association values to apply to parents in the hierarchy
as well, it needs to explicitly specify that (as in passing the hierarchy
categories with their own association value).
I will fix the bug and also make sure the app cannot trip it by accidentally
specifying hierarchical on these categories, or that if it does (cause e.g.
it indexes the categories for both counting and assoc values) then we don't
apply the association to all the categories in the hierarchy.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5876) createCollection(String name, String shards, Integer repl, Integer maxShards, String conf, String routerField, SolrServer server) appears to call itself.
[ https://issues.apache.org/jira/browse/SOLR-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-5876: -- Assignee: Anshum Gupta (was: Mark Miller) createCollection(String name, String shards, Integer repl, Integer maxShards, String conf, String routerField, SolrServer server) appears to call itself. --- Key: SOLR-5876 URL: https://issues.apache.org/jira/browse/SOLR-5876 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Anshum Gupta Fix For: 4.8, 5.0 Attachments: SOLR-5876.patch Causes an infinite recursion. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5876) createCollection(String name, String shards, Integer repl, Integer maxShards, String conf, String routerField, SolrServer server) appears to call itself.
[ https://issues.apache.org/jira/browse/SOLR-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939368#comment-13939368 ] Mark Miller commented on SOLR-5876: --- Thanks Anshum! createCollection(String name, String shards, Integer repl, Integer maxShards, String conf, String routerField, SolrServer server) appears to call itself. --- Key: SOLR-5876 URL: https://issues.apache.org/jira/browse/SOLR-5876 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Anshum Gupta Fix For: 4.8, 5.0 Attachments: SOLR-5876.patch Causes an infinite recursion. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5536) TaxonomyFacetSumInt/FloatAssociations should not rollup()
[
https://issues.apache.org/jira/browse/LUCENE-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939369#comment-13939369
]
Michael McCandless commented on LUCENE-5536:
+1
TaxonomyFacetSumInt/FloatAssociations should not rollup()
-
Key: LUCENE-5536
URL: https://issues.apache.org/jira/browse/LUCENE-5536
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Reporter: Shai Erera
Attachments: LUCENE-5536.patch
Stumbled upon this by accident when I reviewed the code. The previous
associations impl never rolled-up. The assumption is that association values
are given to exact categories and have no hierarchical meaning. For instance
if a document is associated with two categories: {{Category/CS/Algo}} and
{{Category/CS/DataStructure}} with weights {{0.95}} and {{0.43}}
respectively, it is not associated with {{Category/CS}} with weight {{1.38}}!
:)
If the app wants to association values to apply to parents in the hierarchy
as well, it needs to explicitly specify that (as in passing the hierarchy
categories with their own association value).
I will fix the bug and also make sure the app cannot trip it by accidentally
specifying hierarchical on these categories, or that if it does (cause e.g.
it indexes the categories for both counting and assoc values) then we don't
apply the association to all the categories in the hierarchy.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5749) Implement an Overseer status API
[ https://issues.apache.org/jira/browse/SOLR-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939371#comment-13939371 ] Noble Paul commented on SOLR-5749: -- We probably should add statistics on time taken to read the messages from ZK Implement an Overseer status API Key: SOLR-5749 URL: https://issues.apache.org/jira/browse/SOLR-5749 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Shalin Shekhar Mangar Fix For: 5.0 Attachments: SOLR-5749.patch, SOLR-5749.patch Right now there is little to no information exposed about the overseer from SolrCloud. I propose that we have an API for overseer status which can return: # Past N commands executed (grouped by command type) # Status (queue-size, current overseer leader node) # Overseer log -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5536) TaxonomyFacetSumInt/FloatAssociations should not rollup()
[
https://issues.apache.org/jira/browse/LUCENE-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939372#comment-13939372
]
Shai Erera commented on LUCENE-5536:
Don't know that we should because in practice nothing is rolled up. Because
DimConfig.hierarchical=false, and rollup() does {{if (ft.hierarchical
ft.multiValued == false) {}}, it means we're just wasting a fraction of a CPU
today... but there's no bug per se. I will backport if it's important, but I
didn't even plan to mention that in CHANGES :).
TaxonomyFacetSumInt/FloatAssociations should not rollup()
-
Key: LUCENE-5536
URL: https://issues.apache.org/jira/browse/LUCENE-5536
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Reporter: Shai Erera
Attachments: LUCENE-5536.patch
Stumbled upon this by accident when I reviewed the code. The previous
associations impl never rolled-up. The assumption is that association values
are given to exact categories and have no hierarchical meaning. For instance
if a document is associated with two categories: {{Category/CS/Algo}} and
{{Category/CS/DataStructure}} with weights {{0.95}} and {{0.43}}
respectively, it is not associated with {{Category/CS}} with weight {{1.38}}!
:)
If the app wants to association values to apply to parents in the hierarchy
as well, it needs to explicitly specify that (as in passing the hierarchy
categories with their own association value).
I will fix the bug and also make sure the app cannot trip it by accidentally
specifying hierarchical on these categories, or that if it does (cause e.g.
it indexes the categories for both counting and assoc values) then we don't
apply the association to all the categories in the hierarchy.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5536) TaxonomyFacetSumInt/FloatAssociations should not rollup()
[
https://issues.apache.org/jira/browse/LUCENE-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939373#comment-13939373
]
Michael McCandless commented on LUCENE-5536:
Ahh, no real bug. Then we shouldn't backport to 4.7.1.
TaxonomyFacetSumInt/FloatAssociations should not rollup()
-
Key: LUCENE-5536
URL: https://issues.apache.org/jira/browse/LUCENE-5536
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Reporter: Shai Erera
Attachments: LUCENE-5536.patch
Stumbled upon this by accident when I reviewed the code. The previous
associations impl never rolled-up. The assumption is that association values
are given to exact categories and have no hierarchical meaning. For instance
if a document is associated with two categories: {{Category/CS/Algo}} and
{{Category/CS/DataStructure}} with weights {{0.95}} and {{0.43}}
respectively, it is not associated with {{Category/CS}} with weight {{1.38}}!
:)
If the app wants to association values to apply to parents in the hierarchy
as well, it needs to explicitly specify that (as in passing the hierarchy
categories with their own association value).
I will fix the bug and also make sure the app cannot trip it by accidentally
specifying hierarchical on these categories, or that if it does (cause e.g.
it indexes the categories for both counting and assoc values) then we don't
apply the association to all the categories in the hierarchy.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5536) TaxonomyFacetSumInt/FloatAssociations should not rollup()
[
https://issues.apache.org/jira/browse/LUCENE-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939377#comment-13939377
]
ASF subversion and git services commented on LUCENE-5536:
-
Commit 1578952 from [~shaie] in branch 'dev/trunk'
[ https://svn.apache.org/r1578952 ]
LUCENE-5536: don't call rollup() from TaxonomyFacets associations
TaxonomyFacetSumInt/FloatAssociations should not rollup()
-
Key: LUCENE-5536
URL: https://issues.apache.org/jira/browse/LUCENE-5536
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Reporter: Shai Erera
Attachments: LUCENE-5536.patch
Stumbled upon this by accident when I reviewed the code. The previous
associations impl never rolled-up. The assumption is that association values
are given to exact categories and have no hierarchical meaning. For instance
if a document is associated with two categories: {{Category/CS/Algo}} and
{{Category/CS/DataStructure}} with weights {{0.95}} and {{0.43}}
respectively, it is not associated with {{Category/CS}} with weight {{1.38}}!
:)
If the app wants to association values to apply to parents in the hierarchy
as well, it needs to explicitly specify that (as in passing the hierarchy
categories with their own association value).
I will fix the bug and also make sure the app cannot trip it by accidentally
specifying hierarchical on these categories, or that if it does (cause e.g.
it indexes the categories for both counting and assoc values) then we don't
apply the association to all the categories in the hierarchy.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5536) TaxonomyFacetSumInt/FloatAssociations should not rollup()
[
https://issues.apache.org/jira/browse/LUCENE-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939381#comment-13939381
]
ASF subversion and git services commented on LUCENE-5536:
-
Commit 1578954 from [~shaie] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1578954 ]
LUCENE-5536: don't call rollup() from TaxonomyFacets associations
TaxonomyFacetSumInt/FloatAssociations should not rollup()
-
Key: LUCENE-5536
URL: https://issues.apache.org/jira/browse/LUCENE-5536
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Reporter: Shai Erera
Fix For: 4.8, 5.0
Attachments: LUCENE-5536.patch
Stumbled upon this by accident when I reviewed the code. The previous
associations impl never rolled-up. The assumption is that association values
are given to exact categories and have no hierarchical meaning. For instance
if a document is associated with two categories: {{Category/CS/Algo}} and
{{Category/CS/DataStructure}} with weights {{0.95}} and {{0.43}}
respectively, it is not associated with {{Category/CS}} with weight {{1.38}}!
:)
If the app wants to association values to apply to parents in the hierarchy
as well, it needs to explicitly specify that (as in passing the hierarchy
categories with their own association value).
I will fix the bug and also make sure the app cannot trip it by accidentally
specifying hierarchical on these categories, or that if it does (cause e.g.
it indexes the categories for both counting and assoc values) then we don't
apply the association to all the categories in the hierarchy.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5536) TaxonomyFacetSumInt/FloatAssociations should not rollup()
[
https://issues.apache.org/jira/browse/LUCENE-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera resolved LUCENE-5536.
Resolution: Fixed
Fix Version/s: 5.0
4.8
Assignee: Shai Erera
Committed to trunk and 4x.
TaxonomyFacetSumInt/FloatAssociations should not rollup()
-
Key: LUCENE-5536
URL: https://issues.apache.org/jira/browse/LUCENE-5536
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Reporter: Shai Erera
Assignee: Shai Erera
Fix For: 4.8, 5.0
Attachments: LUCENE-5536.patch
Stumbled upon this by accident when I reviewed the code. The previous
associations impl never rolled-up. The assumption is that association values
are given to exact categories and have no hierarchical meaning. For instance
if a document is associated with two categories: {{Category/CS/Algo}} and
{{Category/CS/DataStructure}} with weights {{0.95}} and {{0.43}}
respectively, it is not associated with {{Category/CS}} with weight {{1.38}}!
:)
If the app wants to association values to apply to parents in the hierarchy
as well, it needs to explicitly specify that (as in passing the hierarchy
categories with their own association value).
I will fix the bug and also make sure the app cannot trip it by accidentally
specifying hierarchical on these categories, or that if it does (cause e.g.
it indexes the categories for both counting and assoc values) then we don't
apply the association to all the categories in the hierarchy.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5876) createCollection(String name, String shards, Integer repl, Integer maxShards, String conf, String routerField, SolrServer server) appears to call itself.
[ https://issues.apache.org/jira/browse/SOLR-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta resolved SOLR-5876. Resolution: Fixed createCollection(String name, String shards, Integer repl, Integer maxShards, String conf, String routerField, SolrServer server) appears to call itself. --- Key: SOLR-5876 URL: https://issues.apache.org/jira/browse/SOLR-5876 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Anshum Gupta Fix For: 4.8, 5.0 Attachments: SOLR-5876.patch Causes an infinite recursion. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5872) Eliminate overseer queue
[ https://issues.apache.org/jira/browse/SOLR-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939413#comment-13939413 ] Mark Miller commented on SOLR-5872: --- bq. is to move the replica states out into their own ZK nodes. That is also how I first implemented the clusterstate - it was super slow to read the state and required a ridiculous number of watchers. Now that they have some options to read multiple nodes in one call, it may be that you can work around some of the issues we had, but it was really only good for the case where you had small changes in state to read - users had real issues with performance otherwise and that is why we moved to clusterstate.json. It's a similar issue - we have been there before, we moved because of tough issues, it's should be a high bar to go back. Eliminate overseer queue - Key: SOLR-5872 URL: https://issues.apache.org/jira/browse/SOLR-5872 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Noble Paul Assignee: Noble Paul The overseer queue is one of the busiest points in the entire system. The raison d'être of the queue is * Provide batching of operations for the main clusterstate,json so that state updates are minimized * Avoid race conditions and ensure order Now , as we move the individual collection states out of the main clusterstate.json, the batching is not useful anymore. Race conditions can easily be solved by using a compare and set in Zookeeper. The proposed solution is , whenever an operation is required to be performed on the clusterstate, the same thread (and of course the same JVM) # read the fresh state and version of zk node # construct the new state # perform a compare and set # if compare and set fails go to step 1 This should be limited to all operations performed on external collections because batching would be required for others -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5872) Eliminate overseer queue
[ https://issues.apache.org/jira/browse/SOLR-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939422#comment-13939422 ] Noble Paul edited comment on SOLR-5872 at 3/18/14 4:04 PM: --- bq.That is also how I first implemented the clusterstate Can you throw some light on how was the ZK schema for your initial impl? If all nodes of a given slice is under one zk directory , one watch on the parent should be fine, right? was (Author: noble.paul): bq.That is also how I first implemented the clusterstate Can you throw some light on how was the ZK schema for your initial impl? If all nodes of a given slice is in one watch on the parent should be fine, right? Eliminate overseer queue - Key: SOLR-5872 URL: https://issues.apache.org/jira/browse/SOLR-5872 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Noble Paul Assignee: Noble Paul The overseer queue is one of the busiest points in the entire system. The raison d'être of the queue is * Provide batching of operations for the main clusterstate,json so that state updates are minimized * Avoid race conditions and ensure order Now , as we move the individual collection states out of the main clusterstate.json, the batching is not useful anymore. Race conditions can easily be solved by using a compare and set in Zookeeper. The proposed solution is , whenever an operation is required to be performed on the clusterstate, the same thread (and of course the same JVM) # read the fresh state and version of zk node # construct the new state # perform a compare and set # if compare and set fails go to step 1 This should be limited to all operations performed on external collections because batching would be required for others -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5872) Eliminate overseer queue
[ https://issues.apache.org/jira/browse/SOLR-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939422#comment-13939422 ] Noble Paul commented on SOLR-5872: -- bq.That is also how I first implemented the clusterstate Can you throw some light on how was the ZK schema for your initial impl? If all nodes of a given slice is in one watch on the parent should be fine, right? Eliminate overseer queue - Key: SOLR-5872 URL: https://issues.apache.org/jira/browse/SOLR-5872 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Noble Paul Assignee: Noble Paul The overseer queue is one of the busiest points in the entire system. The raison d'être of the queue is * Provide batching of operations for the main clusterstate,json so that state updates are minimized * Avoid race conditions and ensure order Now , as we move the individual collection states out of the main clusterstate.json, the batching is not useful anymore. Race conditions can easily be solved by using a compare and set in Zookeeper. The proposed solution is , whenever an operation is required to be performed on the clusterstate, the same thread (and of course the same JVM) # read the fresh state and version of zk node # construct the new state # perform a compare and set # if compare and set fails go to step 1 This should be limited to all operations performed on external collections because batching would be required for others -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4478) Allow cores to specify a named config set in non-SolrCloud mode
[ https://issues.apache.org/jira/browse/SOLR-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated SOLR-4478: Attachment: SOLR-4478-take2.patch New patch, adding CoreAdminHandler and solrj integration. Allow cores to specify a named config set in non-SolrCloud mode --- Key: SOLR-4478 URL: https://issues.apache.org/jira/browse/SOLR-4478 Project: Solr Issue Type: Improvement Affects Versions: 4.2, 5.0 Reporter: Erick Erickson Assignee: Alan Woodward Attachments: SOLR-4478-take2.patch, SOLR-4478-take2.patch, SOLR-4478-take2.patch, SOLR-4478-take2.patch, SOLR-4478.patch, SOLR-4478.patch Part of moving forward to the new way, after SOLR-4196 etc... I propose an additional parameter specified on the core node in solr.xml or as a parameter in the discovery mode core.properties file, call it configSet, where the value provided is a path to a directory, either absolute or relative. Really, this is as though you copied the conf directory somewhere to be used by more than one core. Straw-man: There will be a directory solr_home/configsets which will be the default. If the configSet parameter is, say, myconf, then I'd expect a directory named myconf to exist in solr_home/configsets, which would look something like solr_home/configsets/myconf/schema.xml solrconfig.xml stopwords.txt velocity velocity/query.vm etc. If multiple cores used the same configSet, schema, solrconfig etc. would all be shared (i.e. shareSchema=true would be assumed). I don't see a good use-case for _not_ sharing schemas, so I don't propose to allow this to be turned off. Hmmm, what if shareSchema is explicitly set to false in the solr.xml or properties file? I'd guess it should be honored but maybe log a warning? Mostly I'm putting this up for comments. I know that there are already thoughts about how this all should work floating around, so before I start any work on this I thought I'd at least get an idea of whether this is the way people are thinking about going. Configset can be either a relative or absolute path, if relative it's assumed to be relative to solr_home. Thoughts? -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5473) Make one state.json per collection
[ https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-5473: - Attachment: SOLR-5473-74.patch Updated with trunk after SOLR-5477 commit Make one state.json per collection -- Key: SOLR-5473 URL: https://issues.apache.org/jira/browse/SOLR-5473 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Noble Paul Assignee: Noble Paul Attachments: SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, ec2-23-20-119-52_solr.log, ec2-50-16-38-73_solr.log As defined in the parent issue, store the states of each collection under /collections/collectionname/state.json node -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5477) Async execution of OverseerCollectionProcessor tasks
[
https://issues.apache.org/jira/browse/SOLR-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939466#comment-13939466
]
Noble Paul commented on SOLR-5477:
--
Line 222 OverseerCollectionProcessor
{quote}
final String asyncId = (message.containsKey(ASYNC) message.get(ASYNC) !=
null) ? (String) message.get(ASYNC) : null;
{quote}
we should use message.getStr() instead of typecasting to String
Async execution of OverseerCollectionProcessor tasks
Key: SOLR-5477
URL: https://issues.apache.org/jira/browse/SOLR-5477
Project: Solr
Issue Type: Sub-task
Components: SolrCloud
Reporter: Noble Paul
Assignee: Anshum Gupta
Fix For: 4.8, 5.0
Attachments: SOLR-5477-CoreAdminStatus.patch,
SOLR-5477-updated.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch,
SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch,
SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch,
SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch,
SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch,
SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch,
SOLR-5477.urlschemefix.patch
Typical collection admin commands are long running and it is very common to
have the requests get timed out. It is more of a problem if the cluster is
very large.Add an option to run these commands asynchronously
add an extra param async=true for all collection commands
the task is written to ZK and the caller is returned a task id.
as separate collection admin command will be added to poll the status of the
task
command=statusid=7657668909
if id is not passed all running async tasks should be listed
A separate queue is created to store in-process tasks . After the tasks are
completed the queue entry is removed. OverSeerColectionProcessor will perform
these tasks in multiple threads
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5876) CollectionAdminRequest#createCollection(String name, String shards, Integer repl, Integer maxShards, String conf, String routerField, SolrServer server) appears to call
[ https://issues.apache.org/jira/browse/SOLR-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-5876: -- Summary: CollectionAdminRequest#createCollection(String name, String shards, Integer repl, Integer maxShards, String conf, String routerField, SolrServer server) appears to call itself. (was: createCollection(String name, String shards, Integer repl, Integer maxShards, String conf, String routerField, SolrServer server) appears to call itself.) CollectionAdminRequest#createCollection(String name, String shards, Integer repl, Integer maxShards, String conf, String routerField, SolrServer server) appears to call itself. -- Key: SOLR-5876 URL: https://issues.apache.org/jira/browse/SOLR-5876 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Anshum Gupta Fix For: 4.8, 5.0 Attachments: SOLR-5876.patch Causes an infinite recursion. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5477) Async execution of OverseerCollectionProcessor tasks
[
https://issues.apache.org/jira/browse/SOLR-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939466#comment-13939466
]
Noble Paul edited comment on SOLR-5477 at 3/18/14 4:56 PM:
---
Line 222 OverseerCollectionProcessor
{quote}
final String asyncId = (message.containsKey(ASYNC) message.get(ASYNC) !=
null) ? (String) message.get(ASYNC) : null;
{quote}
we should use message.getStr() instead of typecasting to String
Line 237
This code stores data in java serialization format. Can we do json
serialization?
{quote}
head.setBytes(SolrResponse.serializable(response));
{quote}
was (Author: noble.paul):
Line 222 OverseerCollectionProcessor
{quote}
final String asyncId = (message.containsKey(ASYNC) message.get(ASYNC) !=
null) ? (String) message.get(ASYNC) : null;
{quote}
we should use message.getStr() instead of typecasting to String
Async execution of OverseerCollectionProcessor tasks
Key: SOLR-5477
URL: https://issues.apache.org/jira/browse/SOLR-5477
Project: Solr
Issue Type: Sub-task
Components: SolrCloud
Reporter: Noble Paul
Assignee: Anshum Gupta
Fix For: 4.8, 5.0
Attachments: SOLR-5477-CoreAdminStatus.patch,
SOLR-5477-updated.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch,
SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch,
SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch,
SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch,
SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch,
SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch,
SOLR-5477.urlschemefix.patch
Typical collection admin commands are long running and it is very common to
have the requests get timed out. It is more of a problem if the cluster is
very large.Add an option to run these commands asynchronously
add an extra param async=true for all collection commands
the task is written to ZK and the caller is returned a task id.
as separate collection admin command will be added to poll the status of the
task
command=statusid=7657668909
if id is not passed all running async tasks should be listed
A separate queue is created to store in-process tasks . After the tasks are
completed the queue entry is removed. OverSeerColectionProcessor will perform
these tasks in multiple threads
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5748) Introduce autoManageReplicas collection property
[ https://issues.apache.org/jira/browse/SOLR-5748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939479#comment-13939479 ] Noble Paul commented on SOLR-5748: -- bq. It would be good to have some kind of control over where the additional replicas where means? which node or where on the file system? Introduce autoManageReplicas collection property Key: SOLR-5748 URL: https://issues.apache.org/jira/browse/SOLR-5748 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Shalin Shekhar Mangar Fix For: 5.0 I propose to introduce a collection property called autoManageReplicas. This will be used only with the ZK as truth mode. If set to true, then whenever the number of replicas for a shard fall below the replicationFactor and the down nodes do not come back up for a configurable amount of time, additional replicas will be started up automatically. Similarly, if the actual number of replicas is equal to or greater than replicationFactor then if old (previously down) nodes come back up then they will not be allowed to join the shard and will be unloaded instead. I think we should not unload running shards if number of replicas are more for now. We can change that later if needed. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5832) Scary logging from ZkControllerTest suggests test setup isn't doing what it's suppose to
[
https://issues.apache.org/jira/browse/SOLR-5832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13939501#comment-13939501
]
ASF subversion and git services commented on SOLR-5832:
---
Commit 1578974 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1578974 ]
SOLR-5832: Scary logging from ZkControllerTest suggests test setup isn't doing
what it's suppose to.
Scary logging from ZkControllerTest suggests test setup isn't doing what it's
suppose to
Key: SOLR-5832
URL: https://issues.apache.org/jira/browse/SOLR-5832
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Attachments: SOLR-5832.patch
as of trunk r1575397, ZkControllerTest passes for me on every try, but it
logs this every time...
{noformat}
[junit4] 2 11087 T61 oasc.CoreContainer.recordAndThrow ERROR Unable to
create core: collection1 org.apache.solr.common.SolrException: Could not load
config file
/home/hossman/lucene/dev/solr/build/solr-core/test/J0/./ZkControllerTest/collection1/solrconfig.xml
[junit4] 2 at
org.apache.solr.core.CoreContainer.createFromLocal(CoreContainer.java:530)
[junit4] 2 at
org.apache.solr.core.CoreContainer.create(CoreContainer.java:597)
[junit4] 2 at
org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:258)
[junit4] 2 at
org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:250)
[junit4] 2 at
java.util.concurrent.FutureTask.run(FutureTask.java:262)
[junit4] 2 at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
[junit4] 2 at
java.util.concurrent.FutureTask.run(FutureTask.java:262)
[junit4] 2 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[junit4] 2 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[junit4] 2 at java.lang.Thread.run(Thread.java:744)
[junit4] 2 Caused by: java.io.IOException: Can't find resource
'solrconfig.xml' in classpath or
'/home/hossman/lucene/dev/solr/build/solr-core/test/J0/./ZkControllerTest/collection1/conf'
[junit4] 2 at
org.apache.solr.core.SolrResourceLoader.openResource(SolrResourceLoader.java:342)
[junit4] 2 at
org.apache.solr.core.SolrResourceLoader.openConfig(SolrResourceLoader.java:288)
[junit4] 2 at org.apache.solr.core.Config.init(Config.java:116)
[junit4] 2 at org.apache.solr.core.Config.init(Config.java:86)
[junit4] 2 at
org.apache.solr.core.SolrConfig.init(SolrConfig.java:140)
[junit4] 2 at
org.apache.solr.core.CoreContainer.createFromLocal(CoreContainer.java:527)
[junit4] 2 ... 9 more
{noformat}
Suggesting that:
* the CoreContainer initalization isn't working properly
* the tests either doesn't need the SolrCore initialized but it's trying
anyway -- or the test _thinks_ it needs the SolrCore, but isn't using it in a
way that will fail when the SolrCore isn't ther.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
