date:20190712

[JENKINS] Lucene-Solr-repro - Build # 3435 - Still Unstable

2019-07-12 Thread Apache Jenkins Server

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!

2019-07-12 Thread Policeman Jenkins Server

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

[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-11.0.3) - Build # 364 - Still Unstable!

2019-07-12 Thread Policeman Jenkins Server

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

[JENKINS] Lucene-Solr-8.x-Linux (32bit/jdk1.8.0_201) - Build # 865 - Unstable!

2019-07-12 Thread Policeman Jenkins Server

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

2019-07-12 Thread Apache Jenkins Server

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

[GitHub] [lucene-solr] ctargett commented on issue #781: updated the pull request template to make checkboxes work

2019-07-12 Thread GitBox

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

2019-07-12 Thread GitBox

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

2019-07-12 Thread GitBox

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

2019-07-12 Thread GitBox

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

2019-07-12 Thread Apache Jenkins Server

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

2019-07-12 Thread GitBox

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)

2019-07-12 Thread GitBox

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

2019-07-12 Thread Christine Poerschke (JIRA)



[ 
https://issues.apache.org/jira/browse/SOLR-13585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-07-12 Thread Christine Poerschke (JIRA)



[ 
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 
>

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-12.0.1) - Build # 8050 - Still Unstable!

2019-07-12 Thread Policeman Jenkins Server

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)

2019-07-12 Thread GitBox

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

2019-07-12 Thread Bruno Roustant (JIRA)



 [ 
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

2019-07-12 Thread Bruno Roustant (JIRA)



 [ 
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

2019-07-12 Thread Uwe Schindler (JIRA)



[ 
https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-07-12 Thread GitBox

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

2019-07-12 Thread GitBox

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

2019-07-12 Thread GitBox

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

2019-07-12 Thread Tomoko Uchida (JIRA)



[ 
https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-07-12 Thread Cassandra Targett (JIRA)



[ 
https://issues.apache.org/jira/browse/SOLR-8346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-07-12 Thread Bruno Roustant (JIRA)



[ 
https://issues.apache.org/jira/browse/SOLR-11866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-07-12 Thread Jan Høydahl

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=cb366dc4-c136-4505-9c37-60bde5db2550=shareui=1562914476369
> 
> Solr:
> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=120732972=5cace703-b80b-49c4-a07f-55b891683f90=shareui=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 or two. +1 for around July 10th.
>>> > >>
>>> > >> On Mon, Jul 1, 2019 at

[GitHub] [lucene-solr] erikhatcher commented on issue #778: SOLR-10288 remove non minified js

2019-07-12 Thread GitBox

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

2019-07-12 Thread Bruno Roustant (JIRA)



[ 
https://issues.apache.org/jira/browse/SOLR-11866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-07-12 Thread GitBox

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

2019-07-12 Thread Uwe Schindler (JIRA)



[ 
https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-07-12 Thread Uwe Schindler (JIRA)



[ 
https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-07-12 Thread Tomoko Uchida (JIRA)



[ 
https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-07-12 Thread GitBox

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

2019-07-12 Thread GitBox

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?

2019-07-12 Thread Christine Poerschke (BLOOMBERG/ LONDON)

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_pos=1=sticker=ab83af8c-94b8-477e-990d-71575fad5504=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

2019-07-12 Thread Uwe Schindler (JIRA)



[ 
https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-07-12 Thread Uwe Schindler (JIRA)



[ 
https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-07-12 Thread Uwe Schindler (JIRA)



[ 
https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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!

2019-07-12 Thread Policeman Jenkins Server

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

[jira] [Commented] (LUCENE-8911) Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x

2019-07-12 Thread Tomoko Uchida (JIRA)



[ 
https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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!

2019-07-12 Thread Policeman Jenkins Server

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

[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 148 - Still Unstable

2019-07-12 Thread Apache Jenkins Server

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",

Re: Lucene/Solr 8.2.0

2019-07-12 Thread 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=cb366dc4-c136-4505-9c37-60bde5db2550=shareui=1562914476369

Solr:
https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=120732972=5cace703-b80b-49c4-a07f-55b891683f90=shareui=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
>> > >>>
>> > >>> Nicholas Knize, Ph.D., GISP
>> > >>> Geospatial Software Guy  |  Elasticsearch

[GitHub] [lucene-solr] atris commented on issue #779: LUCENE-8762: Introduce Specialized Impacts For Doc + Freq

2019-07-12 Thread GitBox

atris commented on issue #779: LUCENE-8762: Introduce Specialized Impacts For 
Doc + Freq
URL: https://github.com/apache/lucene-solr/pull/779#issuecomment-510768788
 
 
   cc: @jpountz 


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 opened a new pull request #779: LUCENE-8762: Introduce Specialized Impacts For Doc + Freq

2019-07-12 Thread GitBox

atris opened a new pull request #779: LUCENE-8762: Introduce Specialized 
Impacts For Doc + Freq
URL: https://github.com/apache/lucene-solr/pull/779
 
 
   ant test for both Lucene and Solr pass. ant precommit passes as well.
   
   I did not add new tests since multiple existing tests exercise the new 
functionality


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

45 matches

Mail list logo