[JENKINS] Lucene-Solr-repro - Build # 3435 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/3435/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/148/consoleText [repro] Revision: 4f2d7c2ecdb7156c39a56e18d96d3f94b30222e1 [repro] Ant options: -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt [repro] Repro line: ant test -Dtestcase=HdfsAutoAddReplicasIntegrationTest -Dtests.method=testSimple -Dtests.seed=9F28C37D6C7A94B2 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.locale=es-PR -Dtests.timezone=MIT -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: aab166d8305ef143506e57b57da9df37b1c7a2af [repro] git fetch [repro] git checkout 4f2d7c2ecdb7156c39a56e18d96d3f94b30222e1 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] HdfsAutoAddReplicasIntegrationTest [repro] ant compile-test [...truncated 3577 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.HdfsAutoAddReplicasIntegrationTest" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.seed=9F28C37D6C7A94B2 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.locale=es-PR -Dtests.timezone=MIT -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [...truncated 2870 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 1/5 failed: org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest [repro] git checkout aab166d8305ef143506e57b57da9df37b1c7a2af [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 5 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk-12.0.1) - Build # 866 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/866/ Java: 64bit/jdk-12.0.1 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 3 tests failed. FAILED: org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplicaLegacy Error Message: Timeout occurred while waiting response from server at: https://127.0.0.1:36347/solr Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: https://127.0.0.1:36347/solr at __randomizedtesting.SeedInfo.seed([1EB3FFDCC3E06156:67A9E2C855D5FDBE]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:384) at org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplicaLegacy(DeleteReplicaTest.java:264) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) 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:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.State
[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-11.0.3) - Build # 364 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/364/ Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseSerialGC 7 tests failed. FAILED: org.apache.solr.client.solrj.io.stream.StreamDecoratorTest.testClassifyStream Error Message: expected:<0.0> but was:<0.9998245650830389> Stack Trace: java.lang.AssertionError: expected:<0.0> but was:<0.9998245650830389> at __randomizedtesting.SeedInfo.seed([1FD838C750DDA0E0:BA90A2FF6985B974]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:553) at org.junit.Assert.assertEquals(Assert.java:683) at org.apache.solr.client.solrj.io.stream.StreamDecoratorTest.testClassifyStream(StreamDecoratorTest.java:3680) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) 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:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:834) FAILED: org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth Error Message: Software caused connection abort: recv failed Sta
[JENKINS] Lucene-Solr-8.x-Linux (32bit/jdk1.8.0_201) - Build # 865 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/865/ Java: 32bit/jdk1.8.0_201 -server -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.ReindexCollectionTest.testSameTargetReindexing Error Message: num docs expected:<200> but was:<199> Stack Trace: java.lang.AssertionError: num docs expected:<200> but was:<199> at __randomizedtesting.SeedInfo.seed([53BB4951D02E5E57:E6C2A286D748C613]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.apache.solr.cloud.ReindexCollectionTest.indexDocs(ReindexCollectionTest.java:411) at org.apache.solr.cloud.ReindexCollectionTest.doTestSameTargetReindexing(ReindexCollectionTest.java:166) at org.apache.solr.cloud.ReindexCollectionTest.testSameTargetReindexing(ReindexCollectionTest.java:157) 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:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) 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:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748)
[JENKINS] Lucene-Solr-BadApples-NightlyTests-8.x - Build # 25 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-NightlyTests-8.x/25/ 1 tests failed. FAILED: org.apache.lucene.search.TestSearcherManager.testConcurrentIndexCloseSearchAndRefresh Error Message: Captured an uncaught exception in thread: Thread[id=1263, name=Thread-1079, state=RUNNABLE, group=TGRP-TestSearcherManager] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=1263, name=Thread-1079, state=RUNNABLE, group=TGRP-TestSearcherManager] Caused by: java.lang.RuntimeException: java.nio.file.FileSystemException: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-8.x/checkout/lucene/build/core/test/J2/temp/lucene.search.TestSearcherManager_23C537564C8B7120-001/tempDir-001/_69.tvx: Too many open files at __randomizedtesting.SeedInfo.seed([23C537564C8B7120]:0) at org.apache.lucene.search.TestSearcherManager$8.run(TestSearcherManager.java:589) Caused by: java.nio.file.FileSystemException: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-8.x/checkout/lucene/build/core/test/J2/temp/lucene.search.TestSearcherManager_23C537564C8B7120-001/tempDir-001/_69.tvx: Too many open files at org.apache.lucene.mockfile.HandleLimitFS.onOpen(HandleLimitFS.java:48) at org.apache.lucene.mockfile.HandleTrackingFS.callOpenHook(HandleTrackingFS.java:81) at org.apache.lucene.mockfile.HandleTrackingFS.newOutputStream(HandleTrackingFS.java:160) at org.apache.lucene.mockfile.HandleTrackingFS.newOutputStream(HandleTrackingFS.java:129) at org.apache.lucene.mockfile.FilterFileSystemProvider.newOutputStream(FilterFileSystemProvider.java:197) at java.nio.file.Files.newOutputStream(Files.java:216) at org.apache.lucene.store.FSDirectory$FSIndexOutput.(FSDirectory.java:410) at org.apache.lucene.store.FSDirectory$FSIndexOutput.(FSDirectory.java:406) at org.apache.lucene.store.FSDirectory.createOutput(FSDirectory.java:254) at org.apache.lucene.store.MockDirectoryWrapper.createOutput(MockDirectoryWrapper.java:667) at org.apache.lucene.store.LockValidatingDirectoryWrapper.createOutput(LockValidatingDirectoryWrapper.java:44) at org.apache.lucene.store.TrackingDirectoryWrapper.createOutput(TrackingDirectoryWrapper.java:43) at org.apache.lucene.codecs.compressing.CompressingTermVectorsWriter.(CompressingTermVectorsWriter.java:221) at org.apache.lucene.codecs.compressing.CompressingTermVectorsFormat.vectorsWriter(CompressingTermVectorsFormat.java:98) at org.apache.lucene.codecs.asserting.AssertingTermVectorsFormat.vectorsWriter(AssertingTermVectorsFormat.java:49) at org.apache.lucene.index.TermVectorsConsumer.initTermVectorsWriter(TermVectorsConsumer.java:88) at org.apache.lucene.index.TermVectorsConsumer.finishDocument(TermVectorsConsumer.java:103) at org.apache.lucene.index.TermsHash.finishDocument(TermsHash.java:95) at org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:419) at org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:250) at org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:495) at org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1594) at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1213) at org.apache.lucene.search.TestSearcherManager$8.run(TestSearcherManager.java:574) Build Log: [...truncated 1352 lines...] [junit4] Suite: org.apache.lucene.search.TestSearcherManager [junit4] 2> de jul. 12, 2019 5:30:16 PM com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler uncaughtException [junit4] 2> WARNING: Uncaught exception in thread: Thread[Thread-1079,5,TGRP-TestSearcherManager] [junit4] 2> java.lang.RuntimeException: java.nio.file.FileSystemException: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-8.x/checkout/lucene/build/core/test/J2/temp/lucene.search.TestSearcherManager_23C537564C8B7120-001/tempDir-001/_69.tvx: Too many open files [junit4] 2>at __randomizedtesting.SeedInfo.seed([23C537564C8B7120]:0) [junit4] 2>at org.apache.lucene.search.TestSearcherManager$8.run(TestSearcherManager.java:589) [junit4] 2> Caused by: java.nio.file.FileSystemException: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-8.x/checkout/lucene/build/core/test/J2/temp/lucene.search.TestSearcherManager_23C537564C8B7120-001/tempDir-001/_69.tvx: Too many open files [junit4] 2>at org.apache.lucene.mockfile.HandleLimitFS.onOpen(HandleLimitFS.java:48) [junit4] 2>at org.apache.lucene.mockfile.HandleTrackingFS.callOpenHook(HandleTrackingFS.java:81) [junit4] 2>at org.apache.lucene.mockfile.
[GitHub] [lucene-solr] ctargett commented on issue #781: updated the pull request template to make checkboxes work
ctargett commented on issue #781: updated the pull request template to make checkboxes work URL: https://github.com/apache/lucene-solr/pull/781#issuecomment-511029557 I don't really see why I have to review it just because I put an initial template in, but I guess it's fine. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] MarcusSorealheis commented on issue #781: updated the pull request template to make checkboxes work
MarcusSorealheis commented on issue #781: updated the pull request template to make checkboxes work URL: https://github.com/apache/lucene-solr/pull/781#issuecomment-511026258 @ctargett this might be one for you This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] MarcusSorealheis commented on issue #781: updated the pull request template to make checkboxes work
MarcusSorealheis commented on issue #781: updated the pull request template to make checkboxes work URL: https://github.com/apache/lucene-solr/pull/781#issuecomment-511026039 https://user-images.githubusercontent.com/2353608/61157269-8092a300-a4aa-11e9-9f2c-cf5eccd42596.png";> This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] MarcusSorealheis opened a new pull request #781: updated the pull request template to make checkboxes work
MarcusSorealheis opened a new pull request #781: updated the pull request template to make checkboxes work URL: https://github.com/apache/lucene-solr/pull/781 # Description Updated the Pull Request template to render checkboxes work. # Solution Add space in between brackets. # Tests Previewed the changes rendered. # Checklist Please review the following and check all that apply: - [] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [] I have created a Jira issue and added the issue ID to my pull request title. - [] I am authorized to contribute this code to the ASF and have removed any code I do not have a license to distribute. - [] I have developed this patch against the `master` branch. - [] I have run `ant precommit` and the appropriate test suite. - [] I have added tests for my changes. - [] I have added documentation for the Ref Guide (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-8.x - Build # 147 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/147/ No tests ran. Build Log: [...truncated 24963 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2587 links (2117 relative) to 3396 anchors in 259 files [echo] Validated Links & Anchors via: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked [untar] Expanding: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/solr-8.3.0.tgz into /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings ::
[GitHub] [lucene-solr] MarcusSorealheis commented on a change in pull request #778: SOLR-10288 remove non minified js
MarcusSorealheis commented on a change in pull request #778: SOLR-10288 remove non minified js URL: https://github.com/apache/lucene-solr/pull/778#discussion_r303138681 ## File path: solr/webapp/build.xml ## @@ -19,12 +19,12 @@ Solr webapp - + Review comment: oh got. my initial exclude commit broke my web app locally. was trying to figure out what would work nothing had yet. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] cpoerschke commented on a change in pull request #300: SOLR-11831: Skip second grouping step if group.limit is 1 (aka Las Vegas Patch)
cpoerschke commented on a change in pull request #300: SOLR-11831: Skip second grouping step if group.limit is 1 (aka Las Vegas Patch) URL: https://github.com/apache/lucene-solr/pull/300#discussion_r303101673 ## File path: solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java ## @@ -34,17 +41,37 @@ /** * Implementation for transforming {@link SearchGroup} into a {@link NamedList} structure and visa versa. */ -public class SearchGroupsResultTransformer implements ShardResultTransformer, Map> { +public abstract class SearchGroupsResultTransformer implements ShardResultTransformer, Map> { Review comment: Thanks @diegoceccarelli for the SOLR-13585 review! I'll aim to commit it on Monday then. Rebasing on top of that will also pick up other grouping related changes that happened recently-ish i.e. they will be good to have as well. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13585) factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods
[ https://issues.apache.org/jira/browse/SOLR-13585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16884073#comment-16884073 ] Christine Poerschke commented on SOLR-13585: bq. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. * This is a relatively straightforward refactoring change with no obvious/clear/new/good ROI targets to extend existing test coverage. * Lucene/Solr QA Jenkins ran the {{core}} tests. * [~diegoceccarelli] reviewed the patch: https://github.com/apache/lucene-solr/pull/300/files#r303058934 > factor out SearchGroupsResultTransformer.[de]serializeOneSearchGroup methods > > > Key: SOLR-13585 > URL: https://issues.apache.org/jira/browse/SOLR-13585 > Project: Solr > Issue Type: Task >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-13585.patch > > > The {{SearchGroupsResultTransformer}}'s methods {{serializeSearchGroup}} e.g. > [#L110-L127|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L110-L127] > and {{transformToNative}} e.g. > [#L73-L108|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L73-L108] > do quite a few things and factoring out of portions of the code e.g. > [#L114-L120|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L114-L120] > and > [#L83-L99|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.1.1/solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java#L83-L99] > could help with code comprehension. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception
[ https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16884067#comment-16884067 ] Christine Poerschke commented on SOLR-13240: Hmm, probably something to do with the build dependencies i.e. {{solr/solrj}} test runs assuming that a compile happened already previously e.g. {code} ant clean ant compile-test cd solr/solrj ant test -Dtestcase=TestPolicy* {code} > UTILIZENODE action results in an exception > -- > > Key: SOLR-13240 > URL: https://issues.apache.org/jira/browse/SOLR-13240 > Project: Solr > Issue Type: Bug > Components: AutoScaling >Affects Versions: 7.6 >Reporter: Hendrik Haddorp >Priority: Major > Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, > solr-solrj-7.5.0.jar > > > When I invoke the UTILIZENODE action the REST call fails like this after it > moved a few replicas: > { > "responseHeader":{ > "status":500, > "QTime":40220}, > "Operation utilizenode caused > exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException: > Comparison method violates its general contract!", > "exception":{ > "msg":"Comparison method violates its general contract!", > "rspCode":-1}, > "error":{ > "metadata":[ > "error-class","org.apache.solr.common.SolrException", > "root-error-class","org.apache.solr.common.SolrException"], > "msg":"Comparison method violates its general contract!", > "trace":"org.apache.solr.common.SolrException: Comparison method violates > its general contract!\n\tat > org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat > > org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat > > org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat > > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat > > org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat > org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat > org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat > > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat > > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat > > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat > > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat > > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat > > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat > > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat > > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat > > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat > > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat > > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat > > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat > > org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat > > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat > org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat > org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat > > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat > org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)\n\tat > org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)\n\tat > org.eclipse.jetty.util.thread.strategy.Ea
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-12.0.1) - Build # 8050 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/8050/ Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseSerialGC 5 tests failed. FAILED: org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth Error Message: Software caused connection abort: recv failed Stack Trace: javax.net.ssl.SSLException: Software caused connection abort: recv failed at __randomizedtesting.SeedInfo.seed([438E29C06A18E64D:FFE05FD2CE4B6537]:0) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:320) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:258) at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1342) at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:844) at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137) at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153) at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259) at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163) at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56) at org.apache.solr.cloud.SolrCloudAuthTestCase.verifySecurityStatus(SolrCloudAuthTestCase.java:200) at org.apache.solr.cloud.SolrCloudAuthTestCase.verifySecurityStatus(SolrCloudAuthTestCase.java:176) at org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:127) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at
[GitHub] [lucene-solr] diegoceccarelli commented on a change in pull request #300: SOLR-11831: Skip second grouping step if group.limit is 1 (aka Las Vegas Patch)
diegoceccarelli commented on a change in pull request #300: SOLR-11831: Skip second grouping step if group.limit is 1 (aka Las Vegas Patch) URL: https://github.com/apache/lucene-solr/pull/300#discussion_r303058934 ## File path: solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java ## @@ -34,17 +41,37 @@ /** * Implementation for transforming {@link SearchGroup} into a {@link NamedList} structure and visa versa. */ -public class SearchGroupsResultTransformer implements ShardResultTransformer, Map> { +public abstract class SearchGroupsResultTransformer implements ShardResultTransformer, Map> { Review comment: Thanks @cpoerschke https://issues.apache.org/jira/browse/SOLR-13585 Looks good to me, I would merge it and then rebase this code on top of it.. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11866) Support efficient subset matching in query elevation rules
[ https://issues.apache.org/jira/browse/SOLR-11866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Roustant updated SOLR-11866: -- Attachment: (was: SOLR-11866.patch) > Support efficient subset matching in query elevation rules > -- > > Key: SOLR-11866 > URL: https://issues.apache.org/jira/browse/SOLR-11866 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 8.0 >Reporter: Bruno Roustant >Assignee: David Smiley >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Leverages the SOLR-11865 refactoring by introducing a > SubsetMatchElevationProvider in QueryElevationComponent. This provider calls > a new util class TrieSubsetMatcher to efficiently match all query elevation > rules which subset is contained by the current query list of terms. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11866) Support efficient subset matching in query elevation rules
[ https://issues.apache.org/jira/browse/SOLR-11866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Roustant updated SOLR-11866: -- Attachment: (was: 0001-New-SubsetMatchElevationProvider-in-QueryElevationCo.patch) > Support efficient subset matching in query elevation rules > -- > > Key: SOLR-11866 > URL: https://issues.apache.org/jira/browse/SOLR-11866 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 8.0 >Reporter: Bruno Roustant >Assignee: David Smiley >Priority: Major > Attachments: SOLR-11866.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Leverages the SOLR-11865 refactoring by introducing a > SubsetMatchElevationProvider in QueryElevationComponent. This provider calls > a new util class TrieSubsetMatcher to efficiently match all query elevation > rules which subset is contained by the current query list of terms. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8911) Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
[ https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883839#comment-16883839 ] Uwe Schindler commented on LUCENE-8911: --- This would not add any complexity, only at the place where the SPIIterator is consumed you have 2 "adds" to the Map. One for the name field and a second one for the "legacy" name if it's not already there. Anywhere else no changes. > Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x > - > > Key: LUCENE-8911 > URL: https://issues.apache.org/jira/browse/LUCENE-8911 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Tomoko Uchida >Priority: Minor > > In LUCENE-8907 I reverted LUCENE-8778 from the 8x branch. > Can we backport it to 8x branch again, with transparent backwards > compatibility (by emulating the factory loading method of Lucene 8.1)? > I am not so sure about it would be better or not to backport the changes, > however, maybe it is good for Solr to have SOLR-13593 without waiting for > release 9.0. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] erikhatcher commented on a change in pull request #778: SOLR-10288 remove non minified js
erikhatcher commented on a change in pull request #778: SOLR-10288 remove non minified js URL: https://github.com/apache/lucene-solr/pull/778#discussion_r302994809 ## File path: solr/webapp/web/index.html ## @@ -53,8 +53,8 @@ - - + Review comment: my diff in the comment didn't include this, but yeah this is of course necessary too. there's some other references that would need updating too? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] erikhatcher commented on a change in pull request #778: SOLR-10288 remove non minified js
erikhatcher commented on a change in pull request #778: SOLR-10288 remove non minified js URL: https://github.com/apache/lucene-solr/pull/778#discussion_r302994419 ## File path: solr/webapp/build.xml ## @@ -19,12 +19,12 @@ Solr webapp - + Review comment: That's a red herring - or a RAT herring. RAT is a license checker. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] erikhatcher commented on issue #778: SOLR-10288 remove non minified js
erikhatcher commented on issue #778: SOLR-10288 remove non minified js URL: https://github.com/apache/lucene-solr/pull/778#issuecomment-510896539 Maybe something like this? ```$ git diff diff --git a/solr/webapp/build.xml b/solr/webapp/build.xml index 99f8d17b421..0d60d8f3740 100644 --- a/solr/webapp/build.xml +++ b/solr/webapp/build.xml @@ -43,7 +43,7 @@ - + (base) Eriks-MBP:solr erikhatcher$ ls server/solr-webapp/webapp/libs/ angular-chosen.jsangular-sanitize.min.js d3.js jquery-ui.min.js angular-cookies.min.js angular-utf8-base64.min.js highlight.jsjquery.jstree.js angular-resource.min.js angular.min.js jquery-1.7.2.min.js ngtimeago.js angular-route.min.js chosen.jquery.min.js jquery-2.1.3.min.js``` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8911) Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
[ https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883832#comment-16883832 ] Tomoko Uchida commented on LUCENE-8911: --- Hi, I might miss something... but have a question: if we only keep the name provided by the author ("NAME" field) and discard the "old name", does this cause problems for Lucene components or break any internal behaviour? It would affect to client code? I have no strong objection but still do not fully understand the reason why we should introduce some complexity into our code to support multiple names. > Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x > - > > Key: LUCENE-8911 > URL: https://issues.apache.org/jira/browse/LUCENE-8911 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Tomoko Uchida >Priority: Minor > > In LUCENE-8907 I reverted LUCENE-8778 from the 8x branch. > Can we backport it to 8x branch again, with transparent backwards > compatibility (by emulating the factory loading method of Lucene 8.1)? > I am not so sure about it would be better or not to backport the changes, > however, maybe it is good for Solr to have SOLR-13593 without waiting for > release 9.0. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8346) Upgrade Zookeeper to version 3.5.5
[ https://issues.apache.org/jira/browse/SOLR-8346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883831#comment-16883831 ] Cassandra Targett commented on SOLR-8346: - I've got a report of someone not able to get ZK status in the Admin UI when using an external 3.5.5 ensemble with Solr 8.1.1 (before the changes in this issue), but they've added the "4lw.commands.whitelist" param to their zoo.cfg. I'm probably tired but I'm not able to figure out exactly what needed to be changed in the code to support that for an external ensemble - is it expected that the admin UI in pre-8.2 versions would not properly recognize that param? > Upgrade Zookeeper to version 3.5.5 > -- > > Key: SOLR-8346 > URL: https://issues.apache.org/jira/browse/SOLR-8346 > Project: Solr > Issue Type: Task > Components: SolrCloud >Reporter: Jan Høydahl >Assignee: Erick Erickson >Priority: Major > Labels: security, zookeeper > Fix For: master (9.0), 8.2 > > Attachments: SOLR-8346.patch, SOLR-8346.patch, SOLR-8346.patch, > SOLR-8346.patch, SOLR-8346.patch, SOLR_8346.patch > > > Investigate upgrading ZooKeeper to 3.5.x, once released. Primary motivation > for this is SSL support. --Currently a 3.5.4-beta is released (2018-05-17).-- > Version 3.5.5 was released 2019-05-20 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11866) Support efficient subset matching in query elevation rules
[ https://issues.apache.org/jira/browse/SOLR-11866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883819#comment-16883819 ] Bruno Roustant commented on SOLR-11866: --- Also, the doc will need to be updated to explain the support of the new match="subset" param in the elevation rule (in addition to match="exact"). . > Support efficient subset matching in query elevation rules > -- > > Key: SOLR-11866 > URL: https://issues.apache.org/jira/browse/SOLR-11866 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 8.0 >Reporter: Bruno Roustant >Assignee: David Smiley >Priority: Major > Attachments: > 0001-New-SubsetMatchElevationProvider-in-QueryElevationCo.patch, > SOLR-11866.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Leverages the SOLR-11865 refactoring by introducing a > SubsetMatchElevationProvider in QueryElevationComponent. This provider calls > a new util class TrieSubsetMatcher to efficiently match all query elevation > rules which subset is contained by the current query list of terms. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene/Solr 8.2.0
Please use HTTPS in the links to download pages. Jan Høydahl > 12. jul. 2019 kl. 09:04 skrev Ignacio Vera : > > Ishan: I had a look into the issues and I have no objections as far as they > get properly reviewed if possible. It will be good to commit the shortly so > they go through a few CI iterations in case something gets broken. I am > planning to build the first RC early next week as there are no blockers for > the release. > > Steve: Than you so much, I need to work on getting the right permissions. > > Finally I wrote a draft for the release notes for Lucene and Solr. It would > be good if someone with more experience in Solr can review/modify my attempt > as it is difficult for me to know which are the most important bits. Here are > the links to the drafts (not they are in wiki, let me know if you have > problems accessing them): > > Lucene: > https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=120732808&draftShareId=cb366dc4-c136-4505-9c37-60bde5db2550&src=shareui&src.shareui.timestamp=1562914476369 > > Solr: > https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=120732972&draftShareId=5cace703-b80b-49c4-a07f-55b891683f90&src=shareui&src.shareui.timestamp=1562914529931 > >> On Thu, Jul 11, 2019 at 6:36 PM Ishan Chattopadhyaya >> wrote: >> Hi Ignacio, >> I wish to include two security bug fixes (not vulnerabilities, but feature >> regressions due to Authorization plugin), SOLR-13472 and SOLR-13619. I can >> commit both shortly, attempting to write a unit test for it (which is >> proving harder to do than reproducing, fixing and testing manually). Please >> let me know if you have any concerns. >> Regards, >> Ishan >> >>> On Thu, 11 Jul, 2019, 9:12 PM Tomoko Uchida, >>> wrote: >>> Hi Ignacio, >>> >>> LUCENE-8907 was fixed. (I have reverted a series of commits which >>> cause backwards incompatibility on Lucene 8.x.) >>> Thank you for waiting for that! >>> >>> Tomoko >>> >>> 2019年7月11日(木) 22:44 Uwe Schindler : >>> > >>> > Hi, >>> > >>> > >>> > >>> > I enabled the policeman Jenkins Jobs for 8.2 branch. >>> > >>> > >>> > >>> > Uwe >>> > >>> > >>> > >>> > - >>> > >>> > Uwe Schindler >>> > >>> > Achterdiek 19, D-28357 Bremen >>> > >>> > https://www.thetaphi.de >>> > >>> > eMail: u...@thetaphi.de >>> > >>> > >>> > >>> > From: Ignacio Vera >>> > Sent: Thursday, July 11, 2019 1:05 PM >>> > To: dev@lucene.apache.org >>> > Subject: Re: Lucene/Solr 8.2.0 >>> > >>> > >>> > >>> > Hi, >>> > >>> > >>> > >>> > The branch has been created, As a reminder, this branch is on feature >>> > freeze and only documentation or build patches should be committed. I >>> > will be waiting for LUCENE-8907 to start building the first release >>> > candidate. >>> > >>> > Let me know if there is any other blocker before we can start the release >>> > process. >>> > >>> > >>> > >>> > It seems I do not have the permissions to create the Jenkins jobs for >>> > this branch, maybe Steve can help here? >>> > >>> > >>> > >>> > Thanks, >>> > >>> > >>> > >>> > Ignacio >>> > >>> > >>> > >>> > On Thu, Jul 11, 2019 at 4:51 AM David Smiley >>> > wrote: >>> > >>> > BTW for 8.2.0 I updated Solr's CHANGES.txt to split out issues that >>> > seemed to be Improvements that were not really New Features. >>> > >>> > >>> > ~ David Smiley >>> > >>> > Apache Lucene/Solr Search Developer >>> > >>> > http://www.linkedin.com/in/davidwsmiley >>> > >>> > >>> > >>> > >>> > >>> > On Wed, Jul 10, 2019 at 10:38 AM Ignacio Vera wrote: >>> > >>> > Thanks Tomoko for taking care of that. >>> > >>> > >>> > >>> > On Wed, Jul 10, 2019 at 4:03 PM Đạt Cao Mạnh >>> > wrote: >>> > >>> > Hi Ignacio, >>> > >>> > >>> > >>> > 8.1.2 bugfix release will cancelled. You can go ahead with 8.2 release. >>> > >>> > >>> > >>> > Thanks! >>> > >>> > >>> > >>> > On Wed, 10 Jul 2019 at 20:38, Tomoko Uchida >>> > wrote: >>> > >>> > Hi, >>> > I opened a blocker issue a while ago for release 8.2: >>> > https://issues.apache.org/jira/browse/LUCENE-8907 >>> > >>> > Sorry about that, I noticed the backwards incompatibility we have to >>> > deal with today. If there are no objections, I will revert the all >>> > related commits from the branch_8x and 8_2 in a few days. >>> > >>> > Thanks, >>> > Tomoko >>> > >>> > 2019年7月10日(水) 22:02 Ignacio Vera : >>> > > >>> > > Hi, >>> > > >>> > > All the issues listed above has been already committed and I see no >>> > > blockers for release 8.2. I will cut the branch tomorrow around 10am >>> > > CEST and I will wait for the decision on the bug release 8.1.2 to >>> > > schedule the build of the first release candidate. Please let us know >>> > > if this is troublesome for you. >>> > > >>> > > Thanks, >>> > > >>> > > Ignacio >>> > > >>> > > >>> > > On Tue, Jul 2, 2019 at 2:59 AM Joel Bernstein >>> > > wrote: >>> > >> >>> > >> I've got one issue that I'd like to get in >>> > >> (https://issues.apache.org/jira/browse/SOLR-13589), which I should >>> > >> have wrapped up in a day
[GitHub] [lucene-solr] erikhatcher commented on issue #778: SOLR-10288 remove non minified js
erikhatcher commented on issue #778: SOLR-10288 remove non minified js URL: https://github.com/apache/lucene-solr/pull/778#issuecomment-510889895 Let's just remove the non-minimized ones (and correct any references to use the minimized). Any reason to keep the non-minimized here at all? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11866) Support efficient subset matching in query elevation rules
[ https://issues.apache.org/jira/browse/SOLR-11866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883816#comment-16883816 ] Bruno Roustant commented on SOLR-11866: --- I have updated with PR [#780|https://github.com/apache/lucene-solr/pull/780]. Should I remove the obsolete patch files from this Jira issue? > Support efficient subset matching in query elevation rules > -- > > Key: SOLR-11866 > URL: https://issues.apache.org/jira/browse/SOLR-11866 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 8.0 >Reporter: Bruno Roustant >Assignee: David Smiley >Priority: Major > Attachments: > 0001-New-SubsetMatchElevationProvider-in-QueryElevationCo.patch, > SOLR-11866.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Leverages the SOLR-11865 refactoring by introducing a > SubsetMatchElevationProvider in QueryElevationComponent. This provider calls > a new util class TrieSubsetMatcher to efficiently match all query elevation > rules which subset is contained by the current query list of terms. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] bruno-roustant opened a new pull request #780: SOLR-11866: Support efficient subset matching in query elevation rules
bruno-roustant opened a new pull request #780: SOLR-11866: Support efficient subset matching in query elevation rules URL: https://github.com/apache/lucene-solr/pull/780 New SubsetMatchElevationProvider and TrieSubsetMatcher that can elevate documents based on query subset matching very efficiently scalable to a large number of elevation rules. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8911) Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
[ https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883802#comment-16883802 ] Uwe Schindler edited comment on LUCENE-8911 at 7/12/19 1:22 PM: I would not strictly enforce the old naming rules, because the idea behind the NAME field is that the developer of a TokenStream component can decide for a good name that unrelated to class name. E.g., this allows to restructure your classes. The new design was from the beginning made in a way that it's perfectly possible to assign "alias" names for tokenstream components in the future. E.g., we could deprecate an old name and rename something and temporary keep both names for lookup. The NAME field only contains the new one. This is basically the same: Let the developer decide for the name that fit's best for his need. For backwards compatibility just keep the old name. For Solr that's not an issue, as old schemas use class names anyways. For Lucene-Internal components tis is not a problem, as we kept the old names - but I'd like to possibly have the option to rename some of those in the future! was (Author: thetaphi): I would not strictly enforce the old naming rules, because the idea behind the NAME field is that the developer of a TokenStream component can decide for a good name that unrelated to class name. E.g., this allows to restructure your classes. The new design was from the beginning made in a way that it's perfectly possible to assign "alias" names for tokenstream components in the future. E.g., we could deprecate an old name and rename something and temporary keep both names for lookup. The NAME field only contains the new one. This is basically the same: Let the developer decide for the name that fit's best for his need. For backwards compatibility just keep the old name. For Lucene-Internal components tis is not a problem, as we kept the old names - but I'd like to possibly have the option to rename some of those in the future! > Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x > - > > Key: LUCENE-8911 > URL: https://issues.apache.org/jira/browse/LUCENE-8911 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Tomoko Uchida >Priority: Minor > > In LUCENE-8907 I reverted LUCENE-8778 from the 8x branch. > Can we backport it to 8x branch again, with transparent backwards > compatibility (by emulating the factory loading method of Lucene 8.1)? > I am not so sure about it would be better or not to backport the changes, > however, maybe it is good for Solr to have SOLR-13593 without waiting for > release 9.0. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8911) Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
[ https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883802#comment-16883802 ] Uwe Schindler commented on LUCENE-8911: --- I would not strictly enforce the old naming rules, because the idea behind the NAME field is that the developer of a TokenStream component can decide for a good name that unrelated to class name. E.g., this allows to restructure your classes. The new design was from the beginning made in a way that it's perfectly possible to assign "alias" names for tokenstream components in the future. E.g., we could deprecate an old name and rename something and temporary keep both names for lookup. The NAME field only contains the new one. This is basically the same: Let the developer decide for the name that fit's best for his need. For backwards compatibility just keep the old name. For Lucene-Internal components tis is not a problem, as we kept the old names - but I'd like to possibly have the option to rename some of those in the future! > Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x > - > > Key: LUCENE-8911 > URL: https://issues.apache.org/jira/browse/LUCENE-8911 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Tomoko Uchida >Priority: Minor > > In LUCENE-8907 I reverted LUCENE-8778 from the 8x branch. > Can we backport it to 8x branch again, with transparent backwards > compatibility (by emulating the factory loading method of Lucene 8.1)? > I am not so sure about it would be better or not to backport the changes, > however, maybe it is good for Solr to have SOLR-13593 without waiting for > release 9.0. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8911) Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
[ https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883797#comment-16883797 ] Tomoko Uchida commented on LUCENE-8911: --- Hi [~thetaphi], thanks for your comment, I basically agree to your idea. {quote}In addition to extracting the NAME field (which should not fail the SPI lookup) also generate the "old name". Add both names to the map (they may differ, if a user decides to use his own name). {quote} While we can strictly keep consistency of the (old) naming rule by this special treatment, it looks slightly strange to me that a factory temporarily have two names. When upgrading to 9.0.0, the client code that look up custom factories by auto-generated names can be broken. It does not look good to me. The old naming rule is not documented anywhere, as far as I know, so I think it is rather an implementation than interface. Can't we discard the "old name" when the NAME field is provided by the author? I know It is not a big problem at all, I just need a bit more clear interpretation for the "backwards compatibility" here and want to seek the modest way to implement it. > Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x > - > > Key: LUCENE-8911 > URL: https://issues.apache.org/jira/browse/LUCENE-8911 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Tomoko Uchida >Priority: Minor > > In LUCENE-8907 I reverted LUCENE-8778 from the 8x branch. > Can we backport it to 8x branch again, with transparent backwards > compatibility (by emulating the factory loading method of Lucene 8.1)? > I am not so sure about it would be better or not to backport the changes, > however, maybe it is good for Solr to have SOLR-13593 without waiting for > release 9.0. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on issue #769: LUCENE-8905: Better Error Handling For Illegal Arguments
atris commented on issue #769: LUCENE-8905: Better Error Handling For Illegal Arguments URL: https://github.com/apache/lucene-solr/pull/769#issuecomment-510879760 @mikemccand Thanks, updated the PR. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on issue #769: LUCENE-8905: Better Error Handling For Illegal Arguments
atris commented on issue #769: LUCENE-8905: Better Error Handling For Illegal Arguments URL: https://github.com/apache/lucene-solr/pull/769#issuecomment-510879042 @jpountz I updated the PR per comments. Given some of the error stack traces, what is your advice on the next step forward? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr or Lucene stickers?
Following up on Gus' affiliation with the ASF thought, over on the Community Development list there was an "Apache Community Business Cards" discussion and arrangement, https://issues.apache.org/jira/browse/COMDEV-243 has details. Not sure if something similar exists or could exist for stickers too? Christine From: dev@lucene.apache.org At: 07/12/19 05:28:11To: dev@lucene.apache.org Subject: Re: Solr or Lucene stickers? Thanks Nick for the Redbubble reference! I'll use that and upload a Lucene one too, soonish. Gus I'll bring some to the next meetup and Activate as well if you want to get some off me. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Thu, Jul 11, 2019 at 5:52 PM Gus Heck wrote: Hmm, I would be interested perhaps too, but would prefer to buy from a source more clearly affiliated with and benefiting the ASF. On Thu, Jul 11, 2019 at 3:38 PM Nicholas Knize wrote: Redbubble has solr stickers available: https://www.redbubble.com/people/stoorzender/works/24960730-apache-solr?cat_context=all-stickers&grid_pos=1&p=sticker&rbs=ab83af8c-94b8-477e-990d-71575fad5504&ref=shop_grid Probably pretty easy to submit the Lucene logo and have those made as well. On Wed, Jul 10, 2019, 9:57 PM David Smiley wrote: Does anyone know if Lucene or Solr stickers are made available anywhere, perhaps by the ASF? Not only would I like some but some colleagues of mine inquired. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
[jira] [Commented] (LUCENE-8911) Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
[ https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883689#comment-16883689 ] Uwe Schindler commented on LUCENE-8911: --- And Solr should log a schema warning (Lucene can't do this). > Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x > - > > Key: LUCENE-8911 > URL: https://issues.apache.org/jira/browse/LUCENE-8911 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Tomoko Uchida >Priority: Minor > > In LUCENE-8907 I reverted LUCENE-8778 from the 8x branch. > Can we backport it to 8x branch again, with transparent backwards > compatibility (by emulating the factory loading method of Lucene 8.1)? > I am not so sure about it would be better or not to backport the changes, > however, maybe it is good for Solr to have SOLR-13593 without waiting for > release 9.0. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8911) Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
[ https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883687#comment-16883687 ] Uwe Schindler edited comment on LUCENE-8911 at 7/12/19 9:52 AM: My opinion/idea would be the following: - Backport everything to 8.x - In addition to extracting the {{NAME}} field (which should not fail the SPI lookup) also generate the "old name". Add both names to the map (they may differ, if a user decides to use his own name). This would bring both worlds: - Old factories still work (using the old algorithm) to generate the name - New factories would have both names (ideally they should not differ, but with the new aproach the user should be able to decide for his own name, not generated from the factory class name). We should add a test with a fake factory (maybe add a META-INF file to the tests) without NAME to test backwards compatibility. was (Author: thetaphi): My opinion/idea would be the following: - Backport everything to 8.x - In addition to extracting the {{NAME}} field (which should not fail the build) also generate the "old name". Add both names to the map (they may differ, if a user decides to use his own name). This would bring both worlds: - Old factories still work (using the old algorithm) to generate the name - New factories would have both names (ideally they should not differ, but with the new aproach the user should be able to decide for his own name, not generated from the factory class name). We should add a test with a fake factory (maybe add a META-INF file to the tests) without NAME to test backwards compatibility. > Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x > - > > Key: LUCENE-8911 > URL: https://issues.apache.org/jira/browse/LUCENE-8911 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Tomoko Uchida >Priority: Minor > > In LUCENE-8907 I reverted LUCENE-8778 from the 8x branch. > Can we backport it to 8x branch again, with transparent backwards > compatibility (by emulating the factory loading method of Lucene 8.1)? > I am not so sure about it would be better or not to backport the changes, > however, maybe it is good for Solr to have SOLR-13593 without waiting for > release 9.0. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8911) Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
[ https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883687#comment-16883687 ] Uwe Schindler commented on LUCENE-8911: --- My opinion/idea would be the following: - Backport everything to 8.x - In addition to extracting the {{NAME}} field (which should not fail the build) also generate the "old name". Add both names to the map (they may differ, if a user decides to use his own name). This would bring both worlds: - Old factories still work (using the old algorithm) to generate the name - New factories would have both names (ideally they should not differ, but with the new aproach the user should be able to decide for his own name, not generated from the factory class name). We should add a test with a fake factory (maybe add a META-INF file to the tests) without NAME to test backwards compatibility. > Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x > - > > Key: LUCENE-8911 > URL: https://issues.apache.org/jira/browse/LUCENE-8911 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Tomoko Uchida >Priority: Minor > > In LUCENE-8907 I reverted LUCENE-8778 from the 8x branch. > Can we backport it to 8x branch again, with transparent backwards > compatibility (by emulating the factory loading method of Lucene 8.1)? > I am not so sure about it would be better or not to backport the changes, > however, maybe it is good for Solr to have SOLR-13593 without waiting for > release 9.0. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-12.0.1) - Build # 24388 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24388/ Java: 64bit/jdk-12.0.1 -XX:-UseCompressedOops -XX:+UseG1GC 3 tests failed. FAILED: org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica Error Message: Timeout occurred while waiting response from server at: https://127.0.0.1:37757/solr Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: https://127.0.0.1:37757/solr at __randomizedtesting.SeedInfo.seed([9D8261C6745488CF:F79400161CA6C205]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:384) at org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:256) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) 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:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evalua
[jira] [Commented] (LUCENE-8911) Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
[ https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883658#comment-16883658 ] Tomoko Uchida commented on LUCENE-8911: --- I do not have strong feeling about this, but I just start thinking that it could be better if we expose this feature from 8.x as pre-migration steps to 9.0 - especially if it affects to many Lucene and Solr users. Therefore quick-eyed custom factory authors can try their own names from now on. It should be easy to emulate old algorithm in a "lenient way" when the SPI NAME constant is not defined. [~thetaphi] and [~jpountz]: Do you have any thoughts about this? And of course we need to add some note about it in MIGRATE.txt anyway, I forgot that. I'll update it. Also, by the way, I feel like that it would be helpful if we can show warning messages for such use case though we don't need full-fledged loggers. But it's beyond the scope here. > Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x > - > > Key: LUCENE-8911 > URL: https://issues.apache.org/jira/browse/LUCENE-8911 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Tomoko Uchida >Priority: Minor > > In LUCENE-8907 I reverted LUCENE-8778 from the 8x branch. > Can we backport it to 8x branch again, with transparent backwards > compatibility (by emulating the factory loading method of Lucene 8.1)? > I am not so sure about it would be better or not to backport the changes, > however, maybe it is good for Solr to have SOLR-13593 without waiting for > release 9.0. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-12.0.1) - Build # 363 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/363/ Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseSerialGC 16 tests failed. FAILED: org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplicaLegacy Error Message: Timeout occurred while waiting response from server at: https://127.0.0.1:63214/solr Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: https://127.0.0.1:63214/solr at __randomizedtesting.SeedInfo.seed([865D4CC58EB8D9EC:FF4751D1188D4504]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:384) at org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplicaLegacy(DeleteReplicaTest.java:264) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) 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:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.Statement
[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 148 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/148/ 1 tests failed. FAILED: org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest.testSimple Error Message: Waiting for collection testSimple2 Timeout waiting to see state for collection=testSimple2 :DocCollection(testSimple2//collections/testSimple2/state.json/27)={ "pullReplicas":"0", "replicationFactor":"2", "shards":{ "shard1":{ "range":"8000-", "state":"active", "replicas":{ "core_node3":{ "dataDir":"hdfs://localhost:37101/solr_hdfs_home/testSimple2/core_node3/data/", "base_url":"https://127.0.0.1:36486/solr";, "node_name":"127.0.0.1:36486_solr", "type":"NRT", "force_set_state":"false", "ulogDir":"hdfs://localhost:37101/solr_hdfs_home/testSimple2/core_node3/data/tlog", "core":"testSimple2_shard1_replica_n1", "shared_storage":"true", "state":"active", "leader":"true"}, "core_node5":{ "dataDir":"hdfs://localhost:37101/solr_hdfs_home/testSimple2/core_node5/data/", "base_url":"https://127.0.0.1:44087/solr";, "node_name":"127.0.0.1:44087_solr", "type":"NRT", "force_set_state":"false", "ulogDir":"hdfs://localhost:37101/solr_hdfs_home/testSimple2/core_node5/data/tlog", "core":"testSimple2_shard1_replica_n2", "shared_storage":"true", "state":"down"}}}, "shard2":{ "range":"0-7fff", "state":"active", "replicas":{ "core_node7":{ "dataDir":"hdfs://localhost:37101/solr_hdfs_home/testSimple2/core_node7/data/", "base_url":"https://127.0.0.1:36486/solr";, "node_name":"127.0.0.1:36486_solr", "type":"NRT", "force_set_state":"false", "ulogDir":"hdfs://localhost:37101/solr_hdfs_home/testSimple2/core_node7/data/tlog", "core":"testSimple2_shard2_replica_n4", "shared_storage":"true", "state":"active", "leader":"true"}, "core_node8":{ "dataDir":"hdfs://localhost:37101/solr_hdfs_home/testSimple2/core_node8/data/", "base_url":"https://127.0.0.1:44087/solr";, "node_name":"127.0.0.1:44087_solr", "type":"NRT", "force_set_state":"false", "ulogDir":"hdfs://localhost:37101/solr_hdfs_home/testSimple2/core_node8/data/tlog", "core":"testSimple2_shard2_replica_n6", "shared_storage":"true", "state":"down", "router":{"name":"compositeId"}, "maxShardsPerNode":"2", "autoAddReplicas":"true", "nrtReplicas":"2", "tlogReplicas":"0"} Live Nodes: [127.0.0.1:36486_solr, 127.0.0.1:37589_solr] Last available state: DocCollection(testSimple2//collections/testSimple2/state.json/27)={ "pullReplicas":"0", "replicationFactor":"2", "shards":{ "shard1":{ "range":"8000-", "state":"active", "replicas":{ "core_node3":{ "dataDir":"hdfs://localhost:37101/solr_hdfs_home/testSimple2/core_node3/data/", "base_url":"https://127.0.0.1:36486/solr";, "node_name":"127.0.0.1:36486_solr", "type":"NRT", "force_set_state":"false", "ulogDir":"hdfs://localhost:37101/solr_hdfs_home/testSimple2/core_node3/data/tlog", "core":"testSimple2_shard1_replica_n1", "shared_storage":"true", "state":"active", "leader":"true"}, "core_node5":{ "dataDir":"hdfs://localhost:37101/solr_hdfs_home/testSimple2/core_node5/data/", "base_url":"https://127.0.0.1:44087/solr";, "node_name":"127.0.0.1:44087_solr", "type":"NRT", "force_set_state":"false", "ulogDir":"hdfs://localhost:37101/solr_hdfs_home/testSimple2/core_node5/data/tlog", "core":"testSimple2_shard1_replica_n2", "shared_storage":"true", "state":"down"}}}, "shard2":{ "range":"0-7fff", "state":"active", "replicas":{ "core_node7":{ "dataDir":"hdfs://localhost:37101/solr_hdfs_home/testSimple2/core_node7/data/", "base_url":"https://127.0.0.1:36486/solr";, "node_name":"127.0.0.1:36486_solr", "type":"NRT", "force_set_state":"false", "ulogDir":"hdfs://localhost:37101/solr_hdfs_home/testSimple2/core_node7/data/tlog", "core":"testSimple2_shard2_replica_n4", "shared_storage":"true", "state":"active", "leader":"true"}, "core_node8":{ "dataDir":"hdfs://localhost:37101/solr_hdfs_home/testSimple2/core_node8/data/", "base_url":"https://127.0.0.1:44087/solr";, "node_name":"127.0.0.1:44087_solr", "type":"NRT", "force_set_state":"false", "ulogDir":"hdfs://localhost:37101/solr_hdfs
Re: Lucene/Solr 8.2.0
Ishan: I had a look into the issues and I have no objections as far as they get properly reviewed if possible. It will be good to commit the shortly so they go through a few CI iterations in case something gets broken. I am planning to build the first RC early next week as there are no blockers for the release. Steve: Than you so much, I need to work on getting the right permissions. Finally I wrote a draft for the release notes for Lucene and Solr. It would be good if someone with more experience in Solr can review/modify my attempt as it is difficult for me to know which are the most important bits. Here are the links to the drafts (not they are in wiki, let me know if you have problems accessing them): Lucene: https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=120732808&draftShareId=cb366dc4-c136-4505-9c37-60bde5db2550&src=shareui&src.shareui.timestamp=1562914476369 Solr: https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=120732972&draftShareId=5cace703-b80b-49c4-a07f-55b891683f90&src=shareui&src.shareui.timestamp=1562914529931 On Thu, Jul 11, 2019 at 6:36 PM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > Hi Ignacio, > I wish to include two security bug fixes (not vulnerabilities, but feature > regressions due to Authorization plugin), SOLR-13472 and SOLR-13619. I can > commit both shortly, attempting to write a unit test for it (which is > proving harder to do than reproducing, fixing and testing manually). Please > let me know if you have any concerns. > Regards, > Ishan > > On Thu, 11 Jul, 2019, 9:12 PM Tomoko Uchida, > wrote: > >> Hi Ignacio, >> >> LUCENE-8907 was fixed. (I have reverted a series of commits which >> cause backwards incompatibility on Lucene 8.x.) >> Thank you for waiting for that! >> >> Tomoko >> >> 2019年7月11日(木) 22:44 Uwe Schindler : >> > >> > Hi, >> > >> > >> > >> > I enabled the policeman Jenkins Jobs for 8.2 branch. >> > >> > >> > >> > Uwe >> > >> > >> > >> > - >> > >> > Uwe Schindler >> > >> > Achterdiek 19, D-28357 Bremen >> > >> > https://www.thetaphi.de >> > >> > eMail: u...@thetaphi.de >> > >> > >> > >> > From: Ignacio Vera >> > Sent: Thursday, July 11, 2019 1:05 PM >> > To: dev@lucene.apache.org >> > Subject: Re: Lucene/Solr 8.2.0 >> > >> > >> > >> > Hi, >> > >> > >> > >> > The branch has been created, As a reminder, this branch is on feature >> freeze and only documentation or build patches should be committed. I will >> be waiting for LUCENE-8907 to start building the first release candidate. >> > >> > Let me know if there is any other blocker before we can start the >> release process. >> > >> > >> > >> > It seems I do not have the permissions to create the Jenkins jobs for >> this branch, maybe Steve can help here? >> > >> > >> > >> > Thanks, >> > >> > >> > >> > Ignacio >> > >> > >> > >> > On Thu, Jul 11, 2019 at 4:51 AM David Smiley >> wrote: >> > >> > BTW for 8.2.0 I updated Solr's CHANGES.txt to split out issues that >> seemed to be Improvements that were not really New Features. >> > >> > >> > ~ David Smiley >> > >> > Apache Lucene/Solr Search Developer >> > >> > http://www.linkedin.com/in/davidwsmiley >> > >> > >> > >> > >> > >> > On Wed, Jul 10, 2019 at 10:38 AM Ignacio Vera >> wrote: >> > >> > Thanks Tomoko for taking care of that. >> > >> > >> > >> > On Wed, Jul 10, 2019 at 4:03 PM Đạt Cao Mạnh >> wrote: >> > >> > Hi Ignacio, >> > >> > >> > >> > 8.1.2 bugfix release will cancelled. You can go ahead with 8.2 release. >> > >> > >> > >> > Thanks! >> > >> > >> > >> > On Wed, 10 Jul 2019 at 20:38, Tomoko Uchida < >> tomoko.uchida.1...@gmail.com> wrote: >> > >> > Hi, >> > I opened a blocker issue a while ago for release 8.2: >> > https://issues.apache.org/jira/browse/LUCENE-8907 >> > >> > Sorry about that, I noticed the backwards incompatibility we have to >> > deal with today. If there are no objections, I will revert the all >> > related commits from the branch_8x and 8_2 in a few days. >> > >> > Thanks, >> > Tomoko >> > >> > 2019年7月10日(水) 22:02 Ignacio Vera : >> > > >> > > Hi, >> > > >> > > All the issues listed above has been already committed and I see no >> blockers for release 8.2. I will cut the branch tomorrow around 10am CEST >> and I will wait for the decision on the bug release 8.1.2 to schedule the >> build of the first release candidate. Please let us know if this is >> troublesome for you. >> > > >> > > Thanks, >> > > >> > > Ignacio >> > > >> > > >> > > On Tue, Jul 2, 2019 at 2:59 AM Joel Bernstein >> wrote: >> > >> >> > >> I've got one issue that I'd like to get in ( >> https://issues.apache.org/jira/browse/SOLR-13589), which I should have >> wrapped up in a day or two. +1 for around July 10th. >> > >> >> > >> On Mon, Jul 1, 2019 at 5:14 PM Nicholas Knize >> wrote: >> > >>> >> > >>> +1 for starting the 8.2 release process. I think it would be good >> to get the LUCENE-8632 feature into 8.2 along with the BKD improvements and >> changes in LUCENE- and LUCENE-8896 >> > >>> >> > >>> Nic