[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_51) - Build # 13711 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13711/ Java: 64bit/jdk1.8.0_51 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests Error Message: Error from server at https://127.0.0.1:49092/rq_jl/source_collection_shard1_replica1: ClusterState says we are the leader (https://127.0.0.1:49092/rq_jl/source_collection_shard1_replica1), but locally we don't think so. Request came from null Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:49092/rq_jl/source_collection_shard1_replica1: ClusterState says we are the leader (https://127.0.0.1:49092/rq_jl/source_collection_shard1_replica1), but locally we don't think so. Request came from null at __randomizedtesting.SeedInfo.seed([EA39C87A9358B705:E259BD569C569F0E]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:635) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:967) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:107) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:72) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:86) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.index(BaseCdcrDistributedZkTest.java:184) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTestOps(CdcrReplicationDistributedZkTest.java:436) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests(CdcrReplicationDistributedZkTest.java:52) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carr
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2575 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2575/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC
1 tests failed.
FAILED: org.apache.solr.core.TestDynamicLoading.testDynamicLoading
Error Message:
Could not get expected value 'X val changed' for path 'x' full output: {
"responseHeader":{ "status":0, "QTime":0}, "params":{"wt":"json"},
"context":{ "webapp":"", "path":"/test1", "httpMethod":"GET"},
"class":"org.apache.solr.core.BlobStoreTestRequestHandler", "x":"X val"}
Stack Trace:
java.lang.AssertionError: Could not get expected value 'X val changed' for
path 'x' full output: {
"responseHeader":{
"status":0,
"QTime":0},
"params":{"wt":"json"},
"context":{
"webapp":"",
"path":"/test1",
"httpMethod":"GET"},
"class":"org.apache.solr.core.BlobStoreTestRequestHandler",
"x":"X val"}
at
__randomizedtesting.SeedInfo.seed([234BBDD075B957B2:FB0690878264F212]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:411)
at
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:260)
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:497)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
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:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestR
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_51) - Build # 13710 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13710/ Java: 64bit/jdk1.8.0_51 -XX:-UseCompressedOops -XX:+UseSerialGC 2 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([C75661F707DC4B01:6012D9536A6758B8]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplication(CdcrReplicationHandlerTest.java:86) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:51) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluat
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_51) - Build # 5098 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5098/ Java: 64bit/jdk1.8.0_51 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.lucene.rangetree.TestRangeTree.testMultiValuedSortedSet Error Message: dir=.\temp\RangeTreeWriter2453214844782505478 still has file=.\temp\RangeTreeWriter2453214844782505478\size20382.7946562357398785588 Stack Trace: java.lang.AssertionError: dir=.\temp\RangeTreeWriter2453214844782505478 still has file=.\temp\RangeTreeWriter2453214844782505478\size20382.7946562357398785588 at __randomizedtesting.SeedInfo.seed([E796DC58347808A:75003E413103FD44]:0) at org.apache.lucene.rangetree.RangeTreeWriter.directoryIsEmpty(RangeTreeWriter.java:402) at org.apache.lucene.rangetree.RangeTreeWriter.finish(RangeTreeWriter.java:391) at org.apache.lucene.rangetree.RangeTreeDocValuesConsumer.addSortedSetField(RangeTreeDocValuesConsumer.java:144) at org.apache.lucene.codecs.perfield.PerFieldDocValuesFormat$FieldsWriter.addSortedSetField(PerFieldDocValuesFormat.java:131) at org.apache.lucene.codecs.DocValuesConsumer.mergeSortedSetField(DocValuesConsumer.java:736) at org.apache.lucene.codecs.DocValuesConsumer.merge(DocValuesConsumer.java:219) at org.apache.lucene.index.SegmentMerger.mergeDocValues(SegmentMerger.java:150) at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:105) at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4075) at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3650) at org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40) at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1915) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1748) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1705) at org.apache.lucene.index.RandomIndexWriter.forceMerge(RandomIndexWriter.java:408) at org.apache.lucene.rangetree.TestRangeTree.testMultiValuedSortedSet(TestRangeTree.java:229) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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 com.carrotsearch.randomizedtesting.rules.StatementAd
[JENKINS-EA] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b60) - Build # 13527 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13527/ Java: 64bit/jdk1.9.0-ea-b60 -XX:-UseCompressedOops -XX:+UseG1GC -Djava.locale.providers=JRE,SPI All tests passed Build Log: [...truncated 1253 lines...] [junit4] JVM J0: stdout was not empty, see: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/core/test/temp/junit4-J0-20150802_235504_085.sysout [junit4] >>> JVM J0: stdout (verbatim) [junit4] # [junit4] # A fatal error has been detected by the Java Runtime Environment: [junit4] # [junit4] # SIGSEGV (0xb) at pc=0x7f3547f9b51f, pid=7608, tid=139866754520832 [junit4] # [junit4] # JRE version: Java(TM) SE Runtime Environment (9.0-b60) (build 1.9.0-ea-b60) [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-ea-b60 mixed mode linux-amd64 ) [junit4] # Problematic frame: [junit4] # V [libjvm.so+0x48651f] ConcurrentMark::completeCleanup()+0x9f [junit4] # [junit4] # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again [junit4] # [junit4] # An error report file with more information is saved as: [junit4] # /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/core/test/J0/hs_err_pid7608.log [junit4] # [junit4] # If you would like to submit a bug report, please visit: [junit4] # http://bugreport.java.com/bugreport/crash.jsp [junit4] # [junit4] <<< JVM J0: EOF [...truncated 547 lines...] [junit4] ERROR: JVM J0 ended with an exception, command line: /home/jenkins/tools/java/64bit/jdk1.9.0-ea-b60/bin/java -XX:-UseCompressedOops -XX:+UseG1GC -Djava.locale.providers=JRE,SPI -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/heapdumps -ea -esa -Dtests.prefix=tests -Dtests.seed=62C0E5D60386D573 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.3.0 -Dtests.cleanthreads=perMethod -Djava.util.logging.config.file=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/tools/junit4/logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false -Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=3 -DtempDir=./temp -Djava.io.tmpdir=./temp -Djunit4.tempDir=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/core/test/temp -Dcommon.dir=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene -Dclover.db.dir=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/clover/db -Djava.security.policy=/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/tools/junit4/tests.policy -Dtests.LUCENE_VERSION=5.3.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Djdk.map.althashing.threshold=0 -Dtests.leaveTemporary=false -Dtests.filterstacks=true -Dtests.disableHdfs=true -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Dfile.encoding=UTF-8 -classpath /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/codecs/classes/java:/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/test-framework/classes/java:/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/test-framework/lib/junit-4.10.jar:/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/test-framework/lib/randomizedtesting-runner-2.1.13.jar:/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/core/classes/java:/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/core/classes/test:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-launcher.jar:/var/lib/jenkins/.ant/lib/ivy-2.3.0.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jdepend.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-bcel.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jmf.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-junit4.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-xalan2.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-javamail.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jai.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-bsf.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-logging.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-net.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-resolver.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-lo
[jira] [Resolved] (SOLR-3085) New edismax param mm.autoRelax to aid in fixing the dismax/edismax stopwords mm issue
[ https://issues.apache.org/jira/browse/SOLR-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-3085. --- Resolution: Fixed Resolving as fixed. Please re-open if back-porting to 5.x > New edismax param mm.autoRelax to aid in fixing the dismax/edismax stopwords > mm issue > - > > Key: SOLR-3085 > URL: https://issues.apache.org/jira/browse/SOLR-3085 > Project: Solr > Issue Type: Bug > Components: query parsers >Reporter: Jan Høydahl >Assignee: Jan Høydahl > Labels: MinimumShouldMatch, dismax, edismax, stopwords > Fix For: Trunk > > Attachments: SOLR-3085.patch, SOLR-3085.patch, SOLR-3085.patch, > SOLR-3085.patch > > > As discussed here http://search-lucene.com/m/Wr7iz1a95jx and here > http://search-lucene.com/m/Yne042qEyCq1 and here > http://search-lucene.com/m/RfAp82nSsla DisMax has an issue with stopwords if > not all fields used in QF have exactly same stopword lists. > Typical solution is to not use stopwords or harmonize stopword lists across > all fields in your QF, or relax the MM to a lower percentag. Sometimes these > are not acceptable workarounds, and we should find a better solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-3085) New edismax param mm.autoRelax to aid in fixing the dismax/edismax stopwords mm issue
[ https://issues.apache.org/jira/browse/SOLR-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl reassigned SOLR-3085: - Assignee: Jan Høydahl > New edismax param mm.autoRelax to aid in fixing the dismax/edismax stopwords > mm issue > - > > Key: SOLR-3085 > URL: https://issues.apache.org/jira/browse/SOLR-3085 > Project: Solr > Issue Type: Bug > Components: query parsers >Reporter: Jan Høydahl >Assignee: Jan Høydahl > Labels: MinimumShouldMatch, dismax, edismax, stopwords > Fix For: Trunk > > Attachments: SOLR-3085.patch, SOLR-3085.patch, SOLR-3085.patch, > SOLR-3085.patch > > > As discussed here http://search-lucene.com/m/Wr7iz1a95jx and here > http://search-lucene.com/m/Yne042qEyCq1 and here > http://search-lucene.com/m/RfAp82nSsla DisMax has an issue with stopwords if > not all fields used in QF have exactly same stopword lists. > Typical solution is to not use stopwords or harmonize stopword lists across > all fields in your QF, or relax the MM to a lower percentag. Sometimes these > are not acceptable workarounds, and we should find a better solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3085) New edismax param mm.autoRelax to aid in fixing the dismax/edismax stopwords mm issue
[ https://issues.apache.org/jira/browse/SOLR-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-3085: -- Summary: New edismax param mm.autoRelax to aid in fixing the dismax/edismax stopwords mm issue (was: Fix the dismax/edismax stopwords mm issue) > New edismax param mm.autoRelax to aid in fixing the dismax/edismax stopwords > mm issue > - > > Key: SOLR-3085 > URL: https://issues.apache.org/jira/browse/SOLR-3085 > Project: Solr > Issue Type: Bug > Components: query parsers >Reporter: Jan Høydahl > Labels: MinimumShouldMatch, dismax, edismax, stopwords > Fix For: Trunk > > Attachments: SOLR-3085.patch, SOLR-3085.patch, SOLR-3085.patch, > SOLR-3085.patch > > > As discussed here http://search-lucene.com/m/Wr7iz1a95jx and here > http://search-lucene.com/m/Yne042qEyCq1 and here > http://search-lucene.com/m/RfAp82nSsla DisMax has an issue with stopwords if > not all fields used in QF have exactly same stopword lists. > Typical solution is to not use stopwords or harmonize stopword lists across > all fields in your QF, or relax the MM to a lower percentag. Sometimes these > are not acceptable workarounds, and we should find a better solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3085) Fix the dismax/edismax stopwords mm issue
[
https://issues.apache.org/jira/browse/SOLR-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651244#comment-14651244
]
Jan Høydahl commented on SOLR-3085:
---
Due to popular demand, I committed the {{mm.autoRelax}} logic to trunk only,
for people to play with. After some broader exposure there we can consider
porting to 5.x.
The {{mergeStopwords}} idea is spun off into SOLR-7862.
> Fix the dismax/edismax stopwords mm issue
> -
>
> Key: SOLR-3085
> URL: https://issues.apache.org/jira/browse/SOLR-3085
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Jan Høydahl
> Labels: MinimumShouldMatch, dismax, edismax, stopwords
> Fix For: Trunk
>
> Attachments: SOLR-3085.patch, SOLR-3085.patch, SOLR-3085.patch,
> SOLR-3085.patch
>
>
> As discussed here http://search-lucene.com/m/Wr7iz1a95jx and here
> http://search-lucene.com/m/Yne042qEyCq1 and here
> http://search-lucene.com/m/RfAp82nSsla DisMax has an issue with stopwords if
> not all fields used in QF have exactly same stopword lists.
> Typical solution is to not use stopwords or harmonize stopword lists across
> all fields in your QF, or relax the MM to a lower percentag. Sometimes these
> are not acceptable workarounds, and we should find a better solution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7862) Ability to merge stopword lists on the fly for eDisMax
Jan Høydahl created SOLR-7862:
-
Summary: Ability to merge stopword lists on the fly for eDisMax
Key: SOLR-7862
URL: https://issues.apache.org/jira/browse/SOLR-7862
Project: Solr
Issue Type: New Feature
Components: query parsers
Reporter: Jan Høydahl
Fix For: Trunk
Spinoff from SOLR-3085.
New edismax parameter {{mergeStopwords}} which will look at all fieldTypes
involved from the {{qf}} fields, and make sure all stopwords are removed from
all fields. This would help avoiding the 0-hits issue when different qf fields
have different stopword handling.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3085) Fix the dismax/edismax stopwords mm issue
[ https://issues.apache.org/jira/browse/SOLR-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651235#comment-14651235 ] ASF subversion and git services commented on SOLR-3085: --- Commit 1693833 from jan...@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1693833 ] SOLR-3085: New edismax param mm.autoRelax which helps in certain cases of the stopwords/zero-hits issue > Fix the dismax/edismax stopwords mm issue > - > > Key: SOLR-3085 > URL: https://issues.apache.org/jira/browse/SOLR-3085 > Project: Solr > Issue Type: Bug > Components: query parsers >Reporter: Jan Høydahl > Labels: MinimumShouldMatch, dismax, edismax, stopwords > Fix For: Trunk > > Attachments: SOLR-3085.patch, SOLR-3085.patch, SOLR-3085.patch, > SOLR-3085.patch > > > As discussed here http://search-lucene.com/m/Wr7iz1a95jx and here > http://search-lucene.com/m/Yne042qEyCq1 and here > http://search-lucene.com/m/RfAp82nSsla DisMax has an issue with stopwords if > not all fields used in QF have exactly same stopword lists. > Typical solution is to not use stopwords or harmonize stopword lists across > all fields in your QF, or relax the MM to a lower percentag. Sometimes these > are not acceptable workarounds, and we should find a better solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3085) Fix the dismax/edismax stopwords mm issue
[ https://issues.apache.org/jira/browse/SOLR-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-3085: -- Attachment: SOLR-3085.patch Attaching new patch which applied to current trunk. I keep the param name mm.autoRelax since it will relax mm not only at "uneven" stopword removal but for all kind of analysis which ends up with different number of clauses between fields. This is easier to explain in documentation too. > Fix the dismax/edismax stopwords mm issue > - > > Key: SOLR-3085 > URL: https://issues.apache.org/jira/browse/SOLR-3085 > Project: Solr > Issue Type: Bug > Components: query parsers >Reporter: Jan Høydahl > Labels: MinimumShouldMatch, dismax, edismax, stopwords > Fix For: Trunk > > Attachments: SOLR-3085.patch, SOLR-3085.patch, SOLR-3085.patch, > SOLR-3085.patch > > > As discussed here http://search-lucene.com/m/Wr7iz1a95jx and here > http://search-lucene.com/m/Yne042qEyCq1 and here > http://search-lucene.com/m/RfAp82nSsla DisMax has an issue with stopwords if > not all fields used in QF have exactly same stopword lists. > Typical solution is to not use stopwords or harmonize stopword lists across > all fields in your QF, or relax the MM to a lower percentag. Sometimes these > are not acceptable workarounds, and we should find a better solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.7.0_80) - Build # 13525 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13525/ Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test Error Message: expected:<0> but was:<1> Stack Trace: java.lang.AssertionError: expected:<0> but was:<1> at __randomizedtesting.SeedInfo.seed([7F7C9BC4CA05C416:F728A41E64F9A9EE]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test(ChaosMonkeySafeLeaderTest.java:156) 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:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 754 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/754/ 5 tests failed. REGRESSION: org.apache.solr.DistributedIntervalFacetingTest.test Error Message: Captured an uncaught exception in thread: Thread[id=55892, name=Thread-52070, state=RUNNABLE, group=TGRP-DistributedIntervalFacetingTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=55892, name=Thread-52070, state=RUNNABLE, group=TGRP-DistributedIntervalFacetingTest] at __randomizedtesting.SeedInfo.seed([3A45FD73B95720F4:B211C2A917AB4D0C]:0) Caused by: java.lang.RuntimeException: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://127.0.0.1:43852//collection1 at __randomizedtesting.SeedInfo.seed([3A45FD73B95720F4]:0) at org.apache.solr.BaseDistributedSearchTestCase$5.run(BaseDistributedSearchTestCase.java:632) Caused by: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://127.0.0.1:43852//collection1 at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:575) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958) at org.apache.solr.BaseDistributedSearchTestCase$5.run(BaseDistributedSearchTestCase.java:627) Caused by: java.io.InterruptedIOException: Connection has been shut down at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:579) at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.solr.util.SolrHttpClient$SolrSystemDefaultHttpClient.execute(SolrHttpClient.java:54) at org.apache.solr.util.SolrHttpClient$SolrSystemDefaultHttpClient.execute(SolrHttpClient.java:45) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:465) ... 6 more Caused by: org.apache.http.impl.conn.ConnectionShutdownException at org.apache.http.impl.conn.ManagedClientConnectionImpl.ensureConnection(ManagedClientConnectionImpl.java:115) at org.apache.http.impl.conn.ManagedClientConnectionImpl.getSSLSession(ManagedClientConnectionImpl.java:247) at org.apache.http.impl.client.DefaultUserTokenHandler.getUserToken(DefaultUserTokenHandler.java:81) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:550) ... 11 more REGRESSION: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test Error Message: expected:<0> but was:<1> Stack Trace: java.lang.AssertionError: expected:<0> but was:<1> at __randomizedtesting.SeedInfo.seed([3A45FD73B95720F4:B211C2A917AB4D0C]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test(ChaosMonkeySafeLeaderTest.java:156) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.
[jira] [Updated] (SOLR-5882) Introduce score local parameter for {!parent} query parser
[
https://issues.apache.org/jira/browse/SOLR-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-5882:
---
Attachment: SOLR-5882.patch
attaching patch.
* introduce \{!parent score=..}
* it turns out, \{!child} already returns scores always
* introduced util for parsing score enum, it also made query-time join parser
more correct, it throws {{SolrException}} on wrong enum name.
* fix ScoreMode.Min at ToParentBlockJoin and test it
I'm kindly ask to review. Due to the last item, I want to commit it before 5.3
cut.
> Introduce score local parameter for {!parent} query parser
> --
>
> Key: SOLR-5882
> URL: https://issues.apache.org/jira/browse/SOLR-5882
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 4.8
>Reporter: Andrey Kudryavtsev
>Assignee: Mikhail Khludnev
> Fix For: 5.3
>
> Attachments: SOLR-5882.patch, SOLR-5882.patch
>
>
> Today BlockJoinParentQParser creates queries with hardcoded _scoring mode_
> "None":
> {code:borderStyle=solid}
> protected Query createQuery(Query parentList, Query query) {
> return new ToParentBlockJoinQuery(query, getFilter(parentList),
> ScoreMode.None);
> }
> {code}
> Analogically BlockJoinChildQParser creates queries with hardcoded _doScores_
> "false":
> {code:borderStyle=solid}
> protected Query createQuery(Query parentListQuery, Query query) {
> return new ToChildBlockJoinQuery(query, getFilter(parentListQuery),
> false);
> }
> {code}
> I propose to have ability to configure this scoring options via query syntax.
> Syntax for parent queries can be like:
> {code:borderStyle=solid}
> {!parent which=type:parent scoreMode=None|Avg|Max|Total}
> {code}
> For child query:
> {code:borderStyle=solid}
> {!child of=type:parent doScores=true|false}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5882) Introduce score local parameter for {!parent} query parser
[
https://issues.apache.org/jira/browse/SOLR-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-5882:
---
Description:
*TODO* it needs to be updated.
Today BlockJoinParentQParser creates queries with hardcoded _scoring mode_
"None":
{code:borderStyle=solid}
protected Query createQuery(Query parentList, Query query) {
return new ToParentBlockJoinQuery(query, getFilter(parentList),
ScoreMode.None);
}
{code}
Analogically BlockJoinChildQParser creates queries with hardcoded _doScores_
"false":
{code:borderStyle=solid}
protected Query createQuery(Query parentListQuery, Query query) {
return new ToChildBlockJoinQuery(query, getFilter(parentListQuery), false);
}
{code}
I propose to have ability to configure this scoring options via query syntax.
Syntax for parent queries can be like:
{code:borderStyle=solid}
{!parent which=type:parent scoreMode=None|Avg|Max|Total}
{code}
For child query:
{code:borderStyle=solid}
{!child of=type:parent doScores=true|false}
{code}
was:
Today BlockJoinParentQParser creates queries with hardcoded _scoring mode_
"None":
{code:borderStyle=solid}
protected Query createQuery(Query parentList, Query query) {
return new ToParentBlockJoinQuery(query, getFilter(parentList),
ScoreMode.None);
}
{code}
Analogically BlockJoinChildQParser creates queries with hardcoded _doScores_
"false":
{code:borderStyle=solid}
protected Query createQuery(Query parentListQuery, Query query) {
return new ToChildBlockJoinQuery(query, getFilter(parentListQuery), false);
}
{code}
I propose to have ability to configure this scoring options via query syntax.
Syntax for parent queries can be like:
{code:borderStyle=solid}
{!parent which=type:parent scoreMode=None|Avg|Max|Total}
{code}
For child query:
{code:borderStyle=solid}
{!child of=type:parent doScores=true|false}
{code}
> Introduce score local parameter for {!parent} query parser
> --
>
> Key: SOLR-5882
> URL: https://issues.apache.org/jira/browse/SOLR-5882
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 4.8
>Reporter: Andrey Kudryavtsev
>Assignee: Mikhail Khludnev
> Fix For: 5.3
>
> Attachments: SOLR-5882.patch, SOLR-5882.patch
>
>
> *TODO* it needs to be updated.
> Today BlockJoinParentQParser creates queries with hardcoded _scoring mode_
> "None":
> {code:borderStyle=solid}
> protected Query createQuery(Query parentList, Query query) {
> return new ToParentBlockJoinQuery(query, getFilter(parentList),
> ScoreMode.None);
> }
> {code}
> Analogically BlockJoinChildQParser creates queries with hardcoded _doScores_
> "false":
> {code:borderStyle=solid}
> protected Query createQuery(Query parentListQuery, Query query) {
> return new ToChildBlockJoinQuery(query, getFilter(parentListQuery),
> false);
> }
> {code}
> I propose to have ability to configure this scoring options via query syntax.
> Syntax for parent queries can be like:
> {code:borderStyle=solid}
> {!parent which=type:parent scoreMode=None|Avg|Max|Total}
> {code}
> For child query:
> {code:borderStyle=solid}
> {!child of=type:parent doScores=true|false}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5882) Introduce score local parameter for {!parent} query parser
[
https://issues.apache.org/jira/browse/SOLR-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-5882:
---
Summary: Introduce score local parameter for {!parent} query parser (was:
Support scoreMode parameter for BlockJoinParentQParser)
> Introduce score local parameter for {!parent} query parser
> --
>
> Key: SOLR-5882
> URL: https://issues.apache.org/jira/browse/SOLR-5882
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 4.8
>Reporter: Andrey Kudryavtsev
>Assignee: Mikhail Khludnev
> Fix For: 5.3
>
> Attachments: SOLR-5882.patch
>
>
> Today BlockJoinParentQParser creates queries with hardcoded _scoring mode_
> "None":
> {code:borderStyle=solid}
> protected Query createQuery(Query parentList, Query query) {
> return new ToParentBlockJoinQuery(query, getFilter(parentList),
> ScoreMode.None);
> }
> {code}
> Analogically BlockJoinChildQParser creates queries with hardcoded _doScores_
> "false":
> {code:borderStyle=solid}
> protected Query createQuery(Query parentListQuery, Query query) {
> return new ToChildBlockJoinQuery(query, getFilter(parentListQuery),
> false);
> }
> {code}
> I propose to have ability to configure this scoring options via query syntax.
> Syntax for parent queries can be like:
> {code:borderStyle=solid}
> {!parent which=type:parent scoreMode=None|Avg|Max|Total}
> {code}
> For child query:
> {code:borderStyle=solid}
> {!child of=type:parent doScores=true|false}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7846) QTs with $variable does not work with query parameter substitution
[
https://issues.apache.org/jira/browse/SOLR-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651169#comment-14651169
]
Bill Bell commented on SOLR-7846:
-
There is a work around,
PS127
hosp_quality_spec_boost:${pspec:${pspec}}
This works.
> QTs with $variable does not work with query parameter substitution
> --
>
> Key: SOLR-7846
> URL: https://issues.apache.org/jira/browse/SOLR-7846
> Project: Solr
> Issue Type: Bug
>Reporter: Bill Bell
>
> http://yonik.com/solr-query-parameter-substitution/
> This is not working as part of QTs in solrconfig.xml due to XML System
> Property Substitution getting confused in SOLR 5.2.1.
> Cannot load the core, since ${value} is being used for XML parameters for
> system property substitution.
> https://wiki.apache.org/solr/SolrConfigXml#System_property_substitution
> Can we support both?
> PS127
> hosp_quality_spec_boost:${pspec}
> This does not work since it thinks it is a System Property.
> We can check System Property and if not defined assume it is in Query, or
> have a new parameter?
> {noformat}
> ${variable} - for System Properties
> ${{variable}} - for Query Parameters?
> {noformat}
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7854) Remove ZkStateReader.updateClusterState(false)
[ https://issues.apache.org/jira/browse/SOLR-7854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651164#comment-14651164 ] Scott Blum commented on SOLR-7854: -- ty for landing Shalin :) > Remove ZkStateReader.updateClusterState(false) > -- > > Key: SOLR-7854 > URL: https://issues.apache.org/jira/browse/SOLR-7854 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 5.2.1 >Reporter: Scott Blum >Assignee: Shalin Shekhar Mangar >Priority: Minor > Labels: easyfix, newbie > Fix For: 5.3, Trunk > > Attachments: SOLR-7854.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > `updateClusterState(false)` as far as I can tell has zero callers. It's > super pointless anyway, because `updateClusterState(true)` is being used > mostly from test code and in places where someone is trying to force a reload > from ZK (for whatever reason). There's no point in asking for a deferred > update when ZkStateReader is already going to keep itself in sync anyway. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_51) - Build # 13705 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13705/ Java: 32bit/jdk1.8.0_51 -server -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test Error Message: expected:<0> but was:<1> Stack Trace: java.lang.AssertionError: expected:<0> but was:<1> at __randomizedtesting.SeedInfo.seed([CCCAEA3C17C46C44:449ED5E6B93801BC]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test(ChaosMonkeySafeLeaderTest.java:156) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.car
[jira] [Commented] (SOLR-5882) Support scoreMode parameter for BlockJoinParentQParser
[
https://issues.apache.org/jira/browse/SOLR-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651160#comment-14651160
]
Mikhail Khludnev commented on SOLR-5882:
QParser test found a bug in
[ToParentBlockJoinQuery.BlockJoinScorer.nextDoc()|https://github.com/apache/lucene-solr/blob/trunk/lucene/join/src/java/org/apache/lucene/search/join/ToParentBlockJoinQuery.java#L300]
it occurs on ScoreMode.Min
{code}
minScore = Math.min(childFreq, minScore); // shouldn't it be childScore, not
Freq?
{code}
I attach a patch includes this fix and test coverage.
> Support scoreMode parameter for BlockJoinParentQParser
> --
>
> Key: SOLR-5882
> URL: https://issues.apache.org/jira/browse/SOLR-5882
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 4.8
>Reporter: Andrey Kudryavtsev
>Assignee: Mikhail Khludnev
> Fix For: 5.3
>
> Attachments: SOLR-5882.patch
>
>
> Today BlockJoinParentQParser creates queries with hardcoded _scoring mode_
> "None":
> {code:borderStyle=solid}
> protected Query createQuery(Query parentList, Query query) {
> return new ToParentBlockJoinQuery(query, getFilter(parentList),
> ScoreMode.None);
> }
> {code}
> Analogically BlockJoinChildQParser creates queries with hardcoded _doScores_
> "false":
> {code:borderStyle=solid}
> protected Query createQuery(Query parentListQuery, Query query) {
> return new ToChildBlockJoinQuery(query, getFilter(parentListQuery),
> false);
> }
> {code}
> I propose to have ability to configure this scoring options via query syntax.
> Syntax for parent queries can be like:
> {code:borderStyle=solid}
> {!parent which=type:parent scoreMode=None|Avg|Max|Total}
> {code}
> For child query:
> {code:borderStyle=solid}
> {!child of=type:parent doScores=true|false}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6664) Replace SynonymFilter with SynonymGraphFilter
[
https://issues.apache.org/jira/browse/LUCENE-6664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651158#comment-14651158
]
Robert Muir commented on LUCENE-6664:
-
OK, if you say its a generalization, then I am ok. But you are saying current
code in queryparsers won't do the wrong thing?: I know its a tough one, since
it already is somewhat wrong today!? I'm just asking because we dont want to
make it worse or more confusing.
> Replace SynonymFilter with SynonymGraphFilter
> -
>
> Key: LUCENE-6664
> URL: https://issues.apache.org/jira/browse/LUCENE-6664
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6664.patch, LUCENE-6664.patch, LUCENE-6664.patch,
> LUCENE-6664.patch, usa.png, usa_flat.png
>
>
> Spinoff from LUCENE-6582.
> I created a new SynonymGraphFilter (to replace the current buggy
> SynonymFilter), that produces correct graphs (does no "graph
> flattening" itself). I think this makes it simpler.
> This means you must add the FlattenGraphFilter yourself, if you are
> applying synonyms during indexing.
> Index-time syn expansion is a necessarily "lossy" graph transformation
> when multi-token (input or output) synonyms are applied, because the
> index does not store {{posLength}}, so there will always be phrase
> queries that should match but do not, and then phrase queries that
> should not match but do.
> http://blog.mikemccandless.com/2012/04/lucenes-tokenstreams-are-actually.html
> goes into detail about this.
> However, with this new SynonymGraphFilter, if instead you do synonym
> expansion at query time (and don't do the flattening), and you use
> TermAutomatonQuery (future: somehow integrated into a query parser),
> or maybe just "enumerate all paths and make union of PhraseQuery", you
> should get 100% correct matches (not sure about "proper" scoring
> though...).
> This new syn filter still cannot consume an arbitrary graph.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2649) MM ignored in edismax queries with operators
[ https://issues.apache.org/jira/browse/SOLR-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651144#comment-14651144 ] Bill Bell commented on SOLR-2649: - This is pretty critical to edismax. If the fix is good, let's get it checked in. ? > MM ignored in edismax queries with operators > > > Key: SOLR-2649 > URL: https://issues.apache.org/jira/browse/SOLR-2649 > Project: Solr > Issue Type: Bug > Components: query parsers >Reporter: Magnus Bergmark >Assignee: Erick Erickson >Priority: Minor > Fix For: 4.9, Trunk > > Attachments: SOLR-2649-with-Qop.patch, SOLR-2649-with-Qop.patch, > SOLR-2649.diff, SOLR-2649.patch > > > Hypothetical scenario: > 1. User searches for "stocks oil gold" with MM set to "50%" > 2. User adds "-stockings" to the query: "stocks oil gold -stockings" > 3. User gets no hits since MM was ignored and all terms where AND-ed > together > The behavior seems to be intentional, although the reason why is never > explained: > // For correct lucene queries, turn off mm processing if there > // were explicit operators (except for AND). > boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; > (lines 232-234 taken from > tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java) > This makes edismax unsuitable as an replacement to dismax; mm is one of the > primary features of dismax. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2573 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2573/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests Error Message: expected:<10> but was:<4> Stack Trace: java.lang.AssertionError: expected:<10> but was:<4> at __randomizedtesting.SeedInfo.seed([F932A17B2B57E24E:F152D4572459CA45]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTestReplicationAfterLeaderChange(CdcrReplicationDistributedZkTest.java:295) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests(CdcrReplicationDistributedZkTest.java:49) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnore
[jira] [Commented] (LUCENE-6664) Replace SynonymFilter with SynonymGraphFilter
[
https://issues.apache.org/jira/browse/LUCENE-6664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651107#comment-14651107
]
Michael McCandless commented on LUCENE-6664:
bq. I dont agree with changing the.meqning of these posinc/poslen atts in this
way.
Actually, I think this is a natural generalization of the existing
posInc/posLen atts, and we should let graph filters use these attributes.
I think making separate "graph attributes" is a short term hack that will just
cause future problems.
Won't it make interop b/w "graph" and "non-graph" filters a nightmare? E.g.
we'd need separate StopGraphFilter and a StopFilter,
LengthGraphFilter/LengthFilter, etc.?
bq. So i dont understand the point of committjng it this way.
OK I won't commit this.
Really until we have a complete query-time solution here, I suppose this patch
is essentially pointless.
But I was hoping by making it available, other devs would see it and try to
innovate on the query-time side of things.
Are you also -1 on committing this to sandbox?
> Replace SynonymFilter with SynonymGraphFilter
> -
>
> Key: LUCENE-6664
> URL: https://issues.apache.org/jira/browse/LUCENE-6664
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6664.patch, LUCENE-6664.patch, LUCENE-6664.patch,
> LUCENE-6664.patch, usa.png, usa_flat.png
>
>
> Spinoff from LUCENE-6582.
> I created a new SynonymGraphFilter (to replace the current buggy
> SynonymFilter), that produces correct graphs (does no "graph
> flattening" itself). I think this makes it simpler.
> This means you must add the FlattenGraphFilter yourself, if you are
> applying synonyms during indexing.
> Index-time syn expansion is a necessarily "lossy" graph transformation
> when multi-token (input or output) synonyms are applied, because the
> index does not store {{posLength}}, so there will always be phrase
> queries that should match but do not, and then phrase queries that
> should not match but do.
> http://blog.mikemccandless.com/2012/04/lucenes-tokenstreams-are-actually.html
> goes into detail about this.
> However, with this new SynonymGraphFilter, if instead you do synonym
> expansion at query time (and don't do the flattening), and you use
> TermAutomatonQuery (future: somehow integrated into a query parser),
> or maybe just "enumerate all paths and make union of PhraseQuery", you
> should get 100% correct matches (not sure about "proper" scoring
> though...).
> This new syn filter still cannot consume an arbitrary graph.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.7.0_80) - Build # 4968 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4968/ Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.common.cloud.TestZkConfigManager Error Message: Clean up static fields (in @AfterClass?), your test seems to hang on to approximately 111,154,976 bytes (threshold is 10,485,760). Field reference sizes (counted individually): - 7,469,816 bytes, private static org.apache.solr.cloud.ZkTestServer org.apache.solr.common.cloud.TestZkConfigManager.zkServer - 400 bytes, protected static java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome - 328 bytes, public static org.junit.rules.TestRule org.apache.solr.SolrTestCaseJ4.solrClassRules - 144 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp - 80 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.coreName Stack Trace: junit.framework.AssertionFailedError: Clean up static fields (in @AfterClass?), your test seems to hang on to approximately 111,154,976 bytes (threshold is 10,485,760). Field reference sizes (counted individually): - 7,469,816 bytes, private static org.apache.solr.cloud.ZkTestServer org.apache.solr.common.cloud.TestZkConfigManager.zkServer - 400 bytes, protected static java.lang.String org.apache.solr.SolrTestCaseJ4.testSolrHome - 328 bytes, public static org.junit.rules.TestRule org.apache.solr.SolrTestCaseJ4.solrClassRules - 144 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.factoryProp - 80 bytes, private static java.lang.String org.apache.solr.SolrTestCaseJ4.coreName at __randomizedtesting.SeedInfo.seed([8696DB8E4F0387EC]:0) at com.carrotsearch.randomizedtesting.rules.StaticFieldsInvariantRule$1.afterAlways(StaticFieldsInvariantRule.java:127) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 12180 lines...] [junit4] Suite: org.apache.solr.common.cloud.TestZkConfigManager [junit4] 2> Creating dataDir: C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.common.cloud.TestZkConfigManager_8696DB8E4F0387EC-001\init-core-data-001 [junit4] 2> 196677 INFO (SUITE-TestZkConfigManager-seed#[8696DB8E4F0387EC]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) [junit4] 2> 196677 INFO (SUITE-TestZkConfigManager-seed#[8696DB8E4F0387EC]-worker) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 196678 INFO (Thread-433) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 196678 INFO (Thread-433) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 196761 INFO (SUITE-TestZkConfigManager-seed#[8696DB8E4F0387EC]-worker) [] o.a.s.c.ZkTestServer start zk server on port:49192 [junit4] 2> 196763 INFO (TEST-TestZkConfigManager.testUploadConfig-seed#[8696DB8E4F0387EC]) [] o.a.s.SolrTestCaseJ4 ###Starting testUploadConfig [junit4] 2> 196763 INFO (TEST-TestZkConfigManager.testUploadConfig-seed#[8696DB8E4F0387EC]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2> 196765 INFO (TEST-TestZkConfigManager.testUploadConfig-seed#[8696DB8E4F0387EC]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 196768 INFO (zkCallback-273-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@735fd796 name:ZooKeeperConnection Watcher:127.0.0.1:49192 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 196769 INFO (TEST-TestZkConfigManager.testUploadConfig-seed#[8696DB8E4F0387EC]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 196769 INFO (TEST-TestZkConfigManager.testUploadConfig-seed#[8696DB8E4F0387EC]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2> 196769 INFO (TEST-TestZkConfi
[jira] [Commented] (SOLR-7861) Document auto loading of solr.xml from zookeeper
[ https://issues.apache.org/jira/browse/SOLR-7861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651072#comment-14651072 ] Jan Høydahl commented on SOLR-7861: --- Think it is ok, or do others see more places that need change? > Document auto loading of solr.xml from zookeeper > - > > Key: SOLR-7861 > URL: https://issues.apache.org/jira/browse/SOLR-7861 > Project: Solr > Issue Type: Task > Components: documentation >Affects Versions: 5.3 >Reporter: Jan Høydahl >Priority: Minor > Fix For: 5.3 > > > Now that SOLR-7735 is resolved, we'll look for solr.xml in ZK by default in > Cloud mode. Document this in ref-guide. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-7861) Document auto loading of solr.xml from zookeeper
[ https://issues.apache.org/jira/browse/SOLR-7861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl reassigned SOLR-7861: - Assignee: Jan Høydahl > Document auto loading of solr.xml from zookeeper > - > > Key: SOLR-7861 > URL: https://issues.apache.org/jira/browse/SOLR-7861 > Project: Solr > Issue Type: Task > Components: documentation >Affects Versions: 5.3 >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Minor > Fix For: 5.3 > > > Now that SOLR-7735 is resolved, we'll look for solr.xml in ZK by default in > Cloud mode. Document this in ref-guide. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7861) Document auto loading of solr.xml from zookeeper
[ https://issues.apache.org/jira/browse/SOLR-7861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651071#comment-14651071 ] Jan Høydahl commented on SOLR-7861: --- Updated these * https://cwiki.apache.org/confluence/display/solr/Format+of+solr.xml * https://cwiki.apache.org/confluence/display/solr/Solr+Cores+and+solr.xml * https://cwiki.apache.org/confluence/display/solr/Using+ZooKeeper+to+Manage+Configuration+Files * https://cwiki.apache.org/confluence/display/solr/Getting+Started+with+SolrCloud * https://cwiki.apache.org/confluence/display/solr/Taking+Solr+to+Production * https://cwiki.apache.org/confluence/display/solr/Solr+Start+Script+Reference Also modernized the "Solr Cores and solr.xml" page by moving info about historic core tags of solr.xml into an info box and adding text about creating cores and collections through APIs and bin/solr. I added a paragraph for "Using ZooKeeper to Manage Configuration Files" that talks about the need for uploading certain files to ZK before first cluster start. I mentioned security.json as an example, but if that is not yet officially documented I can take it out? > Document auto loading of solr.xml from zookeeper > - > > Key: SOLR-7861 > URL: https://issues.apache.org/jira/browse/SOLR-7861 > Project: Solr > Issue Type: Task > Components: documentation >Affects Versions: 5.3 >Reporter: Jan Høydahl >Priority: Minor > Fix For: 5.3 > > > Now that SOLR-7735 is resolved, we'll look for solr.xml in ZK by default in > Cloud mode. Document this in ref-guide. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - 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.8.0_51) - Build # 13696 - Failure!
Good catch, thanks! -Yonik On Sat, Aug 1, 2015 at 10:26 PM, Shalin Shekhar Mangar wrote: > I committed a fix to the CdcrUpdateLogTest to reset the test hooks. > > On Sun, Aug 2, 2015 at 10:42 AM, Shalin Shekhar Mangar > wrote: >> Yeah, looks like the Cdcr tests is enabling the test hooks in a static >> context and not cleaning up? The TestStressRecovery ends up calling >> the tests hook at CdcrUpdateLogTest.java line 444. Look at the failure >> stack trace: >> >>[junit4] 2> NOTE: reproduce with: ant test >> -Dtestcase=TestStressRecovery -Dtests.method=testStressRecovery >> -Dtests.seed=301358D17C79C090 -Dtests.multiplier=3 -Dtests.slow=true >> -Dtests.locale=lt -Dtests.timezone=America/Havana -Dtests.asserts=true >> -Dtests.file.encoding=UTF-8 >>[junit4] ERROR 92.3s J2 | TestStressRecovery.testStressRecovery <<< >>[junit4]> Throwable #1: >> java.util.concurrent.ExecutionException: java.lang.AssertionError >>[junit4]> at >> __randomizedtesting.SeedInfo.seed([301358D17C79C090:8A29318CE3917F9E]:0) >>[junit4]> at >> java.util.concurrent.FutureTask.report(FutureTask.java:122) >>[junit4]> at java.util.concurrent.FutureTask.get(FutureTask.java:206) >>[junit4]> at >> org.apache.solr.search.TestStressRecovery.testStressRecovery(TestStressRecovery.java:370) >>[junit4]> at java.lang.Thread.run(Thread.java:745) >>[junit4]> Caused by: java.lang.AssertionError >>[junit4]> at >> org.apache.solr.update.CdcrUpdateLogTest$1.run(CdcrUpdateLogTest.java:444) >>[junit4]> at >> org.apache.solr.update.UpdateLog$LogReplayer.doReplay(UpdateLog.java:1320) >>[junit4]> at >> org.apache.solr.update.UpdateLog$LogReplayer.run(UpdateLog.java:1258) >>[junit4]> at >> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) >>[junit4]> at java.util.concurrent.FutureTask.run(FutureTask.java:266) >>[junit4]> at >> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) >> >> On Sun, Aug 2, 2015 at 10:22 AM, Yonik Seeley wrote: >>> It's been two years since this test has failed, and it seems to have >>> failed multiple times recently. The test itself hasn't changed. >>> Anyone have any ideas what has changed here? >>> >>> Hmmm, looking at the output, perhaps this is this just bleed-over from >>> other failing tests? >>> >>> -Yonik >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >> >> >> -- >> Regards, >> Shalin Shekhar Mangar. > > > > -- > Regards, > Shalin Shekhar Mangar. > > - > 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] [Created] (SOLR-7861) Document auto loading of solr.xml from zookeeper
Jan Høydahl created SOLR-7861: - Summary: Document auto loading of solr.xml from zookeeper Key: SOLR-7861 URL: https://issues.apache.org/jira/browse/SOLR-7861 Project: Solr Issue Type: Task Components: documentation Affects Versions: 5.3 Reporter: Jan Høydahl Priority: Minor Fix For: 5.3 Now that SOLR-7735 is resolved, we'll look for solr.xml in ZK by default in Cloud mode. Document this in ref-guide. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7735) Look for solr.xml in Zookeeper by default
[
https://issues.apache.org/jira/browse/SOLR-7735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl resolved SOLR-7735.
---
Resolution: Fixed
Fixed. Opening other issue for documentation
> Look for solr.xml in Zookeeper by default
> -
>
> Key: SOLR-7735
> URL: https://issues.apache.org/jira/browse/SOLR-7735
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-7735.patch, SOLR-7735.patch
>
>
> In SOLR-4718 support was added for reading {{solr.xml}} from ZK by providing
> system property {{solr.solrxml.location=zookeeper}}. If this property is not
> specified, solr.xml is read from SOLR_HOME. This issue is a spinoff from
> SOLR-7727 where start scripts do not support solr.xml in ZK.
> Instead of adding this to start scripts, suggest to simplify the whole logic:
> * If not in cloud mode, require {{solr.xml}} in SOLR_HOME as today
> * If in cloud mode, first look for {{solr.xml}} in ZK, but if not found, load
> from SOLR_HOME as today
> * Remove the need for {{solr.solrxml.location}} property
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7735) Look for solr.xml in Zookeeper by default
[
https://issues.apache.org/jira/browse/SOLR-7735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651026#comment-14651026
]
ASF subversion and git services commented on SOLR-7735:
---
Commit 1693817 from jan...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1693817 ]
SOLR-7735: Look for solr.xml in Zookeeper by default in SolrCloud mode
(backport)
> Look for solr.xml in Zookeeper by default
> -
>
> Key: SOLR-7735
> URL: https://issues.apache.org/jira/browse/SOLR-7735
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-7735.patch, SOLR-7735.patch
>
>
> In SOLR-4718 support was added for reading {{solr.xml}} from ZK by providing
> system property {{solr.solrxml.location=zookeeper}}. If this property is not
> specified, solr.xml is read from SOLR_HOME. This issue is a spinoff from
> SOLR-7727 where start scripts do not support solr.xml in ZK.
> Instead of adding this to start scripts, suggest to simplify the whole logic:
> * If not in cloud mode, require {{solr.xml}} in SOLR_HOME as today
> * If in cloud mode, first look for {{solr.xml}} in ZK, but if not found, load
> from SOLR_HOME as today
> * Remove the need for {{solr.solrxml.location}} property
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60-ea-b24) - Build # 13702 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13702/ Java: 32bit/jdk1.8.0_60-ea-b24 -client -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([7FFD725D86E36543:D8B9CAF9EB5876FA]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplicationAfterPeerSync(CdcrReplicationHandlerTest.java:158) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:53) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.e
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2572 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2572/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([5956039BBCE7E064:DFC2766EB3556189]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication(TestReplicationHandler.java:1317) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 10162 lines...] [junit4] Suite: org.apache.solr.handler.TestReplicationHandler [junit4] 2> Creating dataDir: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_59560
[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b60) - Build # 13701 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13701/ Java: 32bit/jdk1.9.0-ea-b60 -server -XX:+UseSerialGC -Djava.locale.providers=JRE,SPI 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.handler.TestSolrConfigHandlerCloud Error Message: ERROR: SolrIndexSearcher opens=281 closes=280 Stack Trace: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=281 closes=280 at __randomizedtesting.SeedInfo.seed([3614497085EC0A6]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:472) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:238) at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.handler.TestSolrConfigHandlerCloud Error Message: 2 threads leaked from SUITE scope at org.apache.solr.handler.TestSolrConfigHandlerCloud: 1) Thread[id=4105, name=searcherExecutor-2349-thread-1, state=WAITING, group=TGRP-TestSolrConfigHandlerCloud] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)2) Thread[id=3491, name=qtp17690207-3491, state=RUNNABLE, group=TGRP-TestSolrConfigHandlerCloud] at java.util.WeakHashMap.get(WeakHashMap.java:403) at org.apache.solr.servlet.cache.HttpCacheHeaderUtil.calcEtag(HttpCacheHeaderUtil.java:101) at org.apache.solr.servlet.cache.HttpCacheHeaderUtil.doCacheHeaderValidation(HttpCacheHeaderUtil.java:219) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:445) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:198) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:106) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
[jira] [Commented] (LUCENE-6664) Replace SynonymFilter with SynonymGraphFilter
[
https://issues.apache.org/jira/browse/LUCENE-6664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14650697#comment-14650697
]
Robert Muir commented on LUCENE-6664:
-
I dont agree with changing the.meqning of these posinc/poslen atts in this way.
So i dont understand the point of committjng it this way.
This isnt a contajned commit, it tries to alter their semantics. Where zometime
its now this crazy nodeid. Positions are.now ununderstandable in our analysis
api. Is this what we want?
> Replace SynonymFilter with SynonymGraphFilter
> -
>
> Key: LUCENE-6664
> URL: https://issues.apache.org/jira/browse/LUCENE-6664
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6664.patch, LUCENE-6664.patch, LUCENE-6664.patch,
> LUCENE-6664.patch, usa.png, usa_flat.png
>
>
> Spinoff from LUCENE-6582.
> I created a new SynonymGraphFilter (to replace the current buggy
> SynonymFilter), that produces correct graphs (does no "graph
> flattening" itself). I think this makes it simpler.
> This means you must add the FlattenGraphFilter yourself, if you are
> applying synonyms during indexing.
> Index-time syn expansion is a necessarily "lossy" graph transformation
> when multi-token (input or output) synonyms are applied, because the
> index does not store {{posLength}}, so there will always be phrase
> queries that should match but do not, and then phrase queries that
> should not match but do.
> http://blog.mikemccandless.com/2012/04/lucenes-tokenstreams-are-actually.html
> goes into detail about this.
> However, with this new SynonymGraphFilter, if instead you do synonym
> expansion at query time (and don't do the flattening), and you use
> TermAutomatonQuery (future: somehow integrated into a query parser),
> or maybe just "enumerate all paths and make union of PhraseQuery", you
> should get 100% correct matches (not sure about "proper" scoring
> though...).
> This new syn filter still cannot consume an arbitrary graph.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7849) Secure Inter-node communication in a standard mechanism
[
https://issues.apache.org/jira/browse/SOLR-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-7849:
-
Attachment: SOLR-7849.patch
more tests
> Secure Inter-node communication in a standard mechanism
>
>
> Key: SOLR-7849
> URL: https://issues.apache.org/jira/browse/SOLR-7849
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-7849.patch, SOLR-7849.patch
>
>
> Relying on every Authentication plugin to secure the internode communication
> is error prone. Solr can standardize the authentication so that only the
> first request that comes from outside the cluster needs to be authenticated
> by the authentication plugin
> The scheme to protect the communication will be as follows
> * Every Solr node creates a an RSA key pair
> * The private key is kept private and the public key is made available
> through a core admin API
> * If authentication is enabled , every outgoing request will carry an extra
> header {{ SolrAuth :
> encrypt_with_pvt_key( ) }}
> * If authentication is enabled {{SolrDispatchFilter}} would look for this
> header and see the nodename
> ** If the public key of the nodename is available in cache , make a request
> to the node and fetch the public key
> ** If the public key has changed (because of a server restart) decryption
> fails and the public keyis fetched again
> * If the decryption succeeds , the user-name is set to what the header has
> encoded
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7860) Standardize use of HttpSolrClients in Solr
Ramkumar Aiyengar created SOLR-7860:
---
Summary: Standardize use of HttpSolrClients in Solr
Key: SOLR-7860
URL: https://issues.apache.org/jira/browse/SOLR-7860
Project: Solr
Issue Type: Improvement
Reporter: Ramkumar Aiyengar
Priority: Minor
{{HttpShardHandlerFactory}} and {{UpdateShardHandler}} already provide two
places where one can get {{HttpSolrClient}}s with timeouts set up properly
etc., but there are lots of miscellaneous places which instantiate their own,
with hardcoded timeouts. These are just waiting for some environment to realize
the timeouts are not suitable, and not configurable as well. We should
standardize this (anyone knows why there two to begin with?), ideally this
hardcoding shouldn't exist at all..
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60-ea-b24) - Build # 13693 - Still Failing!
I committed a fix.
The test has a "stupid, simple yet hopefully bug free" implementation
of numeric ranges that it compares NumericRangeTreeQuery and
SortedSetRangeTreeQuery against, yet, it had a bug!
Mike McCandless
http://blog.mikemccandless.com
On Sun, Aug 2, 2015 at 5:17 AM, Michael McCandless
wrote:
> New test from https://issues.apache.org/jira/browse/LUCENE-6697 .. I'll dig.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Sat, Aug 1, 2015 at 5:48 PM, Policeman Jenkins Server
> wrote:
>> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13693/
>> Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
>>
>> 1 tests failed.
>> FAILED: org.apache.lucene.rangetree.TestRangeTree.testRandomMedium
>>
>> Error Message:
>> Captured an uncaught exception in thread: Thread[id=66, name=T0,
>> state=RUNNABLE, group=TGRP-TestRangeTree]
>>
>> Stack Trace:
>> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an
>> uncaught exception in thread: Thread[id=66, name=T0, state=RUNNABLE,
>> group=TGRP-TestRangeTree]
>> at
>> __randomizedtesting.SeedInfo.seed([98075E7FD206186F:25D969D793637B09]:0)
>> Caused by: java.lang.AssertionError: T0: iter=315 id=4481 docID=4357
>> value=8305477697912962588 (range: 8305477697912962588 TO
>> 8305477697912962588) expected true but got: false deleted?=false
>> query=NumericRangeTreeQuery:field=sn_value:{8305477697912962588 TO
>> 8305477697912962588]
>> at __randomizedtesting.SeedInfo.seed([98075E7FD206186F]:0)
>> at org.junit.Assert.fail(Assert.java:93)
>> at
>> org.apache.lucene.rangetree.TestRangeTree$4._run(TestRangeTree.java:499)
>> at
>> org.apache.lucene.rangetree.TestRangeTree$4.run(TestRangeTree.java:430)
>>
>>
>>
>>
>> Build Log:
>> [...truncated 7976 lines...]
>>[junit4] Suite: org.apache.lucene.rangetree.TestRangeTree
>>[junit4] 2> ago 01, 2015 9:48:05 PM
>> com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
>> uncaughtException
>>[junit4] 2> WARNING: Uncaught exception in thread:
>> Thread[T0,5,TGRP-TestRangeTree]
>>[junit4] 2> java.lang.AssertionError: T0: iter=315 id=4481 docID=4357
>> value=8305477697912962588 (range: 8305477697912962588 TO
>> 8305477697912962588) expected true but got: false deleted?=false
>> query=NumericRangeTreeQuery:field=sn_value:{8305477697912962588 TO
>> 8305477697912962588]
>>[junit4] 2>at
>> __randomizedtesting.SeedInfo.seed([98075E7FD206186F]:0)
>>[junit4] 2>at org.junit.Assert.fail(Assert.java:93)
>>[junit4] 2>at
>> org.apache.lucene.rangetree.TestRangeTree$4._run(TestRangeTree.java:499)
>>[junit4] 2>at
>> org.apache.lucene.rangetree.TestRangeTree$4.run(TestRangeTree.java:430)
>>[junit4] 2>
>>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestRangeTree
>> -Dtests.method=testRandomMedium -Dtests.seed=98075E7FD206186F
>> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=es_ES
>> -Dtests.timezone=Atlantic/Azores -Dtests.asserts=true
>> -Dtests.file.encoding=ISO-8859-1
>>[junit4] ERROR 5.36s J0 | TestRangeTree.testRandomMedium <<<
>>[junit4]> Throwable #1:
>> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an
>> uncaught exception in thread: Thread[id=66, name=T0, state=RUNNABLE,
>> group=TGRP-TestRangeTree]
>>[junit4]>at
>> __randomizedtesting.SeedInfo.seed([98075E7FD206186F:25D969D793637B09]:0)
>>[junit4]> Caused by: java.lang.AssertionError: T0: iter=315 id=4481
>> docID=4357 value=8305477697912962588 (range: 8305477697912962588 TO
>> 8305477697912962588) expected true but got: false deleted?=false
>> query=NumericRangeTreeQuery:field=sn_value:{8305477697912962588 TO
>> 8305477697912962588]
>>[junit4]>at
>> __randomizedtesting.SeedInfo.seed([98075E7FD206186F]:0)
>>[junit4]>at
>> org.apache.lucene.rangetree.TestRangeTree$4._run(TestRangeTree.java:499)
>>[junit4]>at
>> org.apache.lucene.rangetree.TestRangeTree$4.run(TestRangeTree.java:430)
>>[junit4] IGNOR/A 0.01s J0 | TestRangeTree.testRandomBig
>>[junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly())
>>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene53): {},
>> docValues:{}, sim=RandomSimilarityProvider(queryNorm=false,coord=no): {},
>> locale=es_ES, timezone=Atlantic/Azores
>>[junit4] 2> NOTE: Linux 3.16.0-44-generic i386/Oracle Corporation
>> 1.8.0_60-ea (32-bit)/cpus=12,threads=1,free=234009416,total=268435456
>>[junit4] 2> NOTE: All tests run in this JVM:
>> [TestJakartaRegexpCapabilities, FuzzyLikeThisQueryTest,
>> TestIDVersionPostingsFormat, TestRangeTree]
>>[junit4] Completed [11/16] on J0 in 16.07s, 14 tests, 1 error, 1 skipped
>> <<< FAILURES!
>>
>> [...truncated 32 lines...]
>> BUILD FAILED
>> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:716: The
[jira] [Commented] (LUCENE-6697) Use 1D KD tree for alternative to postings based numeric range filters
[ https://issues.apache.org/jira/browse/LUCENE-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14650676#comment-14650676 ] ASF subversion and git services commented on LUCENE-6697: - Commit 1693801 from [~mikemccand] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1693801 ] LUCENE-6697: test bug: the stupid-simple-yet-hopefully-bug-free numeric range filter was buggy > Use 1D KD tree for alternative to postings based numeric range filters > -- > > Key: LUCENE-6697 > URL: https://issues.apache.org/jira/browse/LUCENE-6697 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.3, Trunk > > Attachments: LUCENE-6697.patch, LUCENE-6697.patch, LUCENE-6697.patch > > > Today Lucene uses postings to index a numeric value at multiple > precision levels for fast range searching. It's somewhat costly: each > numeric value is indexed with multiple terms (4 terms by default) > ... I think a dedicated 1D BKD tree should be more compact and perform > better. > It should also easily generalize beyond 64 bits to arbitrary byte[], > e.g. for LUCENE-5596, but I haven't explored that here. > A 1D BKD tree just sorts all values, and then indexes adjacent leaf > blocks of size 512-1024 (by default) values per block, and their > docIDs, into a fully balanced binary tree. Building the range filter > is then just a recursive walk through this tree. > It's the same structure we use for 2D lat/lon BKD tree, just with 1D > instead. I implemented it as a DocValuesFormat that also writes the > numeric tree on the side. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6697) Use 1D KD tree for alternative to postings based numeric range filters
[ https://issues.apache.org/jira/browse/LUCENE-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14650675#comment-14650675 ] ASF subversion and git services commented on LUCENE-6697: - Commit 1693800 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1693800 ] LUCENE-6697: test bug: the stupid-simple-yet-hopefully-bug-free numeric range filter was buggy > Use 1D KD tree for alternative to postings based numeric range filters > -- > > Key: LUCENE-6697 > URL: https://issues.apache.org/jira/browse/LUCENE-6697 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.3, Trunk > > Attachments: LUCENE-6697.patch, LUCENE-6697.patch, LUCENE-6697.patch > > > Today Lucene uses postings to index a numeric value at multiple > precision levels for fast range searching. It's somewhat costly: each > numeric value is indexed with multiple terms (4 terms by default) > ... I think a dedicated 1D BKD tree should be more compact and perform > better. > It should also easily generalize beyond 64 bits to arbitrary byte[], > e.g. for LUCENE-5596, but I haven't explored that here. > A 1D BKD tree just sorts all values, and then indexes adjacent leaf > blocks of size 512-1024 (by default) values per block, and their > docIDs, into a fully balanced binary tree. Building the range filter > is then just a recursive walk through this tree. > It's the same structure we use for 2D lat/lon BKD tree, just with 1D > instead. I implemented it as a DocValuesFormat that also writes the > numeric tree on the side. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7859) Clamp down on use of System.currentTimeMillis
Ramkumar Aiyengar created SOLR-7859: --- Summary: Clamp down on use of System.currentTimeMillis Key: SOLR-7859 URL: https://issues.apache.org/jira/browse/SOLR-7859 Project: Solr Issue Type: Improvement Reporter: Ramkumar Aiyengar We did one round of this in SOLR-5734, but more places seem to keep cropping up. We should do one more round, and start whitelisting places which really need it using forbidden-apis. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7819) ZkController.ensureReplicaInLeaderInitiatedRecovery does not respect retryOnConnLoss
[
https://issues.apache.org/jira/browse/SOLR-7819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14650674#comment-14650674
]
Ramkumar Aiyengar commented on SOLR-7819:
-
A couple of comments, looks sensible overall..
{code}
log.info("Node " + replicaNodeName +
" is not live, so skipping leader-initiated recovery for replica:
core={} coreNodeName={}",
replicaCoreName, replicaCoreNodeName);
// publishDownState will be false to avoid publishing the "down" state
too many times
// as many errors can occur together and will each call into this method
(SOLR-6189)
{code}
It goes ahead and does `publishDownState` still if `forcePublishState` is true,
is that intentional? The caller does check for if the replica is live, but
there could a race. Similarly, if our state is suspect due to zk
disconnect/session (the block before this), should the force be respected?
{code}
// if the replica's state is not DOWN right now, make it so ...
// we only really need to try to send the recovery command if the node
itself is "live"
if
(getZkStateReader().getClusterState().liveNodesContain(replicaNodeName)) {
LeaderInitiatedRecoveryThread lirThread =
{code}
The comment doesn't make sense as the code has moved to LIRT.
> ZkController.ensureReplicaInLeaderInitiatedRecovery does not respect
> retryOnConnLoss
>
>
> Key: SOLR-7819
> URL: https://issues.apache.org/jira/browse/SOLR-7819
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 5.2, 5.2.1
>Reporter: Shalin Shekhar Mangar
> Labels: Jepsen
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-7819.patch, SOLR-7819.patch
>
>
> SOLR-7245 added a retryOnConnLoss parameter to
> ZkController.ensureReplicaInLeaderInitiatedRecovery so that indexing threads
> do not hang during a partition on ZK operations. However, some of those
> changes were unintentionally reverted by SOLR-7336 in 5.2.
> I found this while running Jepsen tests on 5.2.1 where a hung update managed
> to put a leader into a 'down' state (I'm still investigating and will open a
> separate issue about this problem).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6664) Replace SynonymFilter with SynonymGraphFilter
[
https://issues.apache.org/jira/browse/LUCENE-6664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-6664:
---
Attachment: LUCENE-6664.patch
New patch, making the new filters public and experimental again.
I also improved the naming.
[~rcmuir] is this OK? Or do you think which attributes to use should block
committing this? I can also put this in sandbox?
> Replace SynonymFilter with SynonymGraphFilter
> -
>
> Key: LUCENE-6664
> URL: https://issues.apache.org/jira/browse/LUCENE-6664
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6664.patch, LUCENE-6664.patch, LUCENE-6664.patch,
> LUCENE-6664.patch, usa.png, usa_flat.png
>
>
> Spinoff from LUCENE-6582.
> I created a new SynonymGraphFilter (to replace the current buggy
> SynonymFilter), that produces correct graphs (does no "graph
> flattening" itself). I think this makes it simpler.
> This means you must add the FlattenGraphFilter yourself, if you are
> applying synonyms during indexing.
> Index-time syn expansion is a necessarily "lossy" graph transformation
> when multi-token (input or output) synonyms are applied, because the
> index does not store {{posLength}}, so there will always be phrase
> queries that should match but do not, and then phrase queries that
> should not match but do.
> http://blog.mikemccandless.com/2012/04/lucenes-tokenstreams-are-actually.html
> goes into detail about this.
> However, with this new SynonymGraphFilter, if instead you do synonym
> expansion at query time (and don't do the flattening), and you use
> TermAutomatonQuery (future: somehow integrated into a query parser),
> or maybe just "enumerate all paths and make union of PhraseQuery", you
> should get 100% correct matches (not sure about "proper" scoring
> though...).
> This new syn filter still cannot consume an arbitrary graph.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6710) GeoPointField should use full 64 bit encoding
[ https://issues.apache.org/jira/browse/LUCENE-6710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-6710. Resolution: Fixed Fix Version/s: Trunk 5.3 Thanks [~nknize]! > GeoPointField should use full 64 bit encoding > - > > Key: LUCENE-6710 > URL: https://issues.apache.org/jira/browse/LUCENE-6710 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Nicholas Knize > Fix For: 5.3, Trunk > > Attachments: LUCENE-6710.patch, LUCENE-6710.patch > > > Current GeoPointField uses 31 bits for each lat and long, respectively. This > causes a precision error for the maximum bounds for 2D mapping applications > (e.g., instead of maximum of 180, 90 the max value handled is 179.99, > 89.99). > This issue improves precision for the full 2D map boundaries by using the > full 32 bit range for lat/lon values, resulting in a morton hash using the > full 64 bit range. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6710) GeoPointField should use full 64 bit encoding
[ https://issues.apache.org/jira/browse/LUCENE-6710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14650665#comment-14650665 ] ASF subversion and git services commented on LUCENE-6710: - Commit 1693797 from [~mikemccand] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1693797 ] LUCENE-6710: use full 64 bits precision for GeoPointField > GeoPointField should use full 64 bit encoding > - > > Key: LUCENE-6710 > URL: https://issues.apache.org/jira/browse/LUCENE-6710 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Nicholas Knize > Fix For: 5.3, Trunk > > Attachments: LUCENE-6710.patch, LUCENE-6710.patch > > > Current GeoPointField uses 31 bits for each lat and long, respectively. This > causes a precision error for the maximum bounds for 2D mapping applications > (e.g., instead of maximum of 180, 90 the max value handled is 179.99, > 89.99). > This issue improves precision for the full 2D map boundaries by using the > full 32 bit range for lat/lon values, resulting in a morton hash using the > full 64 bit range. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6710) GeoPointField should use full 64 bit encoding
[ https://issues.apache.org/jira/browse/LUCENE-6710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14650664#comment-14650664 ] ASF subversion and git services commented on LUCENE-6710: - Commit 1693796 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1693796 ] LUCENE-6710: use full 64 bits precision for GeoPointField > GeoPointField should use full 64 bit encoding > - > > Key: LUCENE-6710 > URL: https://issues.apache.org/jira/browse/LUCENE-6710 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Nicholas Knize > Attachments: LUCENE-6710.patch, LUCENE-6710.patch > > > Current GeoPointField uses 31 bits for each lat and long, respectively. This > causes a precision error for the maximum bounds for 2D mapping applications > (e.g., instead of maximum of 180, 90 the max value handled is 179.99, > 89.99). > This issue improves precision for the full 2D map boundaries by using the > full 32 bit range for lat/lon values, resulting in a morton hash using the > full 64 bit range. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60-ea-b24) - Build # 13693 - Still Failing!
New test from https://issues.apache.org/jira/browse/LUCENE-6697 .. I'll dig.
Mike McCandless
http://blog.mikemccandless.com
On Sat, Aug 1, 2015 at 5:48 PM, Policeman Jenkins Server
wrote:
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13693/
> Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseG1GC
>
> 1 tests failed.
> FAILED: org.apache.lucene.rangetree.TestRangeTree.testRandomMedium
>
> Error Message:
> Captured an uncaught exception in thread: Thread[id=66, name=T0,
> state=RUNNABLE, group=TGRP-TestRangeTree]
>
> Stack Trace:
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an
> uncaught exception in thread: Thread[id=66, name=T0, state=RUNNABLE,
> group=TGRP-TestRangeTree]
> at
> __randomizedtesting.SeedInfo.seed([98075E7FD206186F:25D969D793637B09]:0)
> Caused by: java.lang.AssertionError: T0: iter=315 id=4481 docID=4357
> value=8305477697912962588 (range: 8305477697912962588 TO 8305477697912962588)
> expected true but got: false deleted?=false
> query=NumericRangeTreeQuery:field=sn_value:{8305477697912962588 TO
> 8305477697912962588]
> at __randomizedtesting.SeedInfo.seed([98075E7FD206186F]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at
> org.apache.lucene.rangetree.TestRangeTree$4._run(TestRangeTree.java:499)
> at
> org.apache.lucene.rangetree.TestRangeTree$4.run(TestRangeTree.java:430)
>
>
>
>
> Build Log:
> [...truncated 7976 lines...]
>[junit4] Suite: org.apache.lucene.rangetree.TestRangeTree
>[junit4] 2> ago 01, 2015 9:48:05 PM
> com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
> uncaughtException
>[junit4] 2> WARNING: Uncaught exception in thread:
> Thread[T0,5,TGRP-TestRangeTree]
>[junit4] 2> java.lang.AssertionError: T0: iter=315 id=4481 docID=4357
> value=8305477697912962588 (range: 8305477697912962588 TO 8305477697912962588)
> expected true but got: false deleted?=false
> query=NumericRangeTreeQuery:field=sn_value:{8305477697912962588 TO
> 8305477697912962588]
>[junit4] 2>at
> __randomizedtesting.SeedInfo.seed([98075E7FD206186F]:0)
>[junit4] 2>at org.junit.Assert.fail(Assert.java:93)
>[junit4] 2>at
> org.apache.lucene.rangetree.TestRangeTree$4._run(TestRangeTree.java:499)
>[junit4] 2>at
> org.apache.lucene.rangetree.TestRangeTree$4.run(TestRangeTree.java:430)
>[junit4] 2>
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestRangeTree
> -Dtests.method=testRandomMedium -Dtests.seed=98075E7FD206186F
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=es_ES
> -Dtests.timezone=Atlantic/Azores -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR 5.36s J0 | TestRangeTree.testRandomMedium <<<
>[junit4]> Throwable #1:
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an
> uncaught exception in thread: Thread[id=66, name=T0, state=RUNNABLE,
> group=TGRP-TestRangeTree]
>[junit4]>at
> __randomizedtesting.SeedInfo.seed([98075E7FD206186F:25D969D793637B09]:0)
>[junit4]> Caused by: java.lang.AssertionError: T0: iter=315 id=4481
> docID=4357 value=8305477697912962588 (range: 8305477697912962588 TO
> 8305477697912962588) expected true but got: false deleted?=false
> query=NumericRangeTreeQuery:field=sn_value:{8305477697912962588 TO
> 8305477697912962588]
>[junit4]>at
> __randomizedtesting.SeedInfo.seed([98075E7FD206186F]:0)
>[junit4]>at
> org.apache.lucene.rangetree.TestRangeTree$4._run(TestRangeTree.java:499)
>[junit4]>at
> org.apache.lucene.rangetree.TestRangeTree$4.run(TestRangeTree.java:430)
>[junit4] IGNOR/A 0.01s J0 | TestRangeTree.testRandomBig
>[junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly())
>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene53): {},
> docValues:{}, sim=RandomSimilarityProvider(queryNorm=false,coord=no): {},
> locale=es_ES, timezone=Atlantic/Azores
>[junit4] 2> NOTE: Linux 3.16.0-44-generic i386/Oracle Corporation
> 1.8.0_60-ea (32-bit)/cpus=12,threads=1,free=234009416,total=268435456
>[junit4] 2> NOTE: All tests run in this JVM:
> [TestJakartaRegexpCapabilities, FuzzyLikeThisQueryTest,
> TestIDVersionPostingsFormat, TestRangeTree]
>[junit4] Completed [11/16] on J0 in 16.07s, 14 tests, 1 error, 1 skipped
> <<< FAILURES!
>
> [...truncated 32 lines...]
> BUILD FAILED
> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:716: The following
> error occurred while executing this line:
> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:660: The following
> error occurred while executing this line:
> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:59: The following
> error occurred while executing this line:
> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:470: The
> following error occurred while execut
[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b24) - Build # 13698 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13698/ Java: 64bit/jdk1.8.0_60-ea-b24 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests Error Message: Timeout while trying to assert update logs @ collection=source_collection Stack Trace: java.lang.AssertionError: Timeout while trying to assert update logs @ collection=source_collection at __randomizedtesting.SeedInfo.seed([95B1B17FAF41090C:9DD1C453A04F2107]:0) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.assertNumberOfTlogFiles(CdcrReplicationDistributedZkTest.java:644) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTestUpdateLogSynchronisation(CdcrReplicationDistributedZkTest.java:374) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests(CdcrReplicationDistributedZkTest.java:50) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java
