[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-12-ea+12) - Build # 23054 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23054/
Java: 64bit/jdk-12-ea+12 -XX:+UseCompressedOops -XX:+UseG1GC

52 tests failed.
FAILED:  
org.apache.solr.client.solrj.impl.CloudSolrClientTest.checkCollectionParameters

Error Message:
expected:<3> but was:<1>

Stack Trace:
java.lang.AssertionError: expected:<3> but was:<1>
at 
__randomizedtesting.SeedInfo.seed([3D85A12A4961FC20:C692329A10362B97]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.checkCollectionParameters(CloudSolrClientTest.java:602)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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:835)

[JENKINS] Lucene-Solr-repro - Build # 1721 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/1721/

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/184/consoleText

[repro] Revision: e6f6f352cfc30517235822b3deed83df1ee144c6

[repro] Repro line:  ant test  -Dtestcase=ScheduledMaintenanceTriggerTest 
-Dtests.method=testInactiveShardCleanup -Dtests.seed=8BB1AED47ED1CBD7 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=fr-LU -Dtests.timezone=Etc/GMT+11 -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=MoveReplicaTest -Dtests.method=test 
-Dtests.seed=8BB1AED47ED1CBD7 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=ro-RO -Dtests.timezone=Asia/Kuala_Lumpur 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
1a8188d92b8148f2d937bd038f48f103526fcbcc
[repro] git fetch
[repro] git checkout e6f6f352cfc30517235822b3deed83df1ee144c6

[...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]   MoveReplicaTest
[repro]   ScheduledMaintenanceTriggerTest
[repro] ant compile-test

[...truncated 3424 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.MoveReplicaTest|*.ScheduledMaintenanceTriggerTest" 
-Dtests.showOutput=onerror  -Dtests.seed=8BB1AED47ED1CBD7 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ro-RO 
-Dtests.timezone=Asia/Kuala_Lumpur -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[...truncated 7350 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.cloud.MoveReplicaTest
[repro]   5/5 failed: 
org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest

[repro] Re-testing 100% failures at the tip of master
[repro] git fetch
[repro] git checkout master

[...truncated 4 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 8 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   ScheduledMaintenanceTriggerTest
[repro] ant compile-test

[...truncated 3300 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.ScheduledMaintenanceTriggerTest" -Dtests.showOutput=onerror  
-Dtests.seed=8BB1AED47ED1CBD7 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=fr-LU -Dtests.timezone=Etc/GMT+11 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

[...truncated 1145 lines...]
[repro] Setting last failure code to 256

[repro] Failures at the tip of master:
[repro]   2/5 failed: 
org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest
[repro] git checkout 1a8188d92b8148f2d937bd038f48f103526fcbcc

[...truncated 8 lines...]
[repro] Exiting with code 256

[...truncated 6 lines...]

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-BadApples-Tests-7.x - Build # 190 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/190/

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testVersionsAreReturned

Error Message:
Error from server at 
https://127.0.0.1:42753/solr/collection1_shard2_replica_n2: Expected mime type 
application/octet-stream but got text/html.Error 404 
Can not find: /solr/collection1_shard2_replica_n2/update  
HTTP ERROR 404 Problem accessing 
/solr/collection1_shard2_replica_n2/update. Reason: Can not find: 
/solr/collection1_shard2_replica_n2/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605  
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at https://127.0.0.1:42753/solr/collection1_shard2_replica_n2: Expected 
mime type application/octet-stream but got text/html. 


Error 404 Can not find: 
/solr/collection1_shard2_replica_n2/update

HTTP ERROR 404
Problem accessing /solr/collection1_shard2_replica_n2/update. Reason:
Can not find: 
/solr/collection1_shard2_replica_n2/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605




at 
__randomizedtesting.SeedInfo.seed([7D130DC52E46D34A:85D5F4F0BD5F4B82]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:551)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1016)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:237)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testVersionsAreReturned(CloudSolrClientTest.java:725)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-11) - Build # 2938 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2938/
Java: 64bit/jdk-11 -XX:-UseCompressedOops -XX:+UseParallelGC

40 tests failed.
FAILED:  
org.apache.solr.client.solrj.impl.CloudSolrClientTest.preferReplicaTypesTest

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([FFBA128BB519AD29:C450B13DD2806025]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.queryWithPreferReplicaTypes(CloudSolrClientTest.java:970)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.preferReplicaTypesTest(CloudSolrClientTest.java:901)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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:  

[JENKINS] Lucene-Solr-Tests-master - Build # 2884 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2884/

2 tests failed.
FAILED:  
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testVersionsAreReturned

Error Message:
Error from server at http://127.0.0.1:43925/solr/collection1_shard2_replica_n3: 
Expected mime type application/octet-stream but got text/html.   
 
Error 404 Can not find: 
/solr/collection1_shard2_replica_n3/update  HTTP ERROR 
404 Problem accessing /solr/collection1_shard2_replica_n3/update. 
Reason: Can not find: 
/solr/collection1_shard2_replica_n3/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605  
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:43925/solr/collection1_shard2_replica_n3: Expected 
mime type application/octet-stream but got text/html. 


Error 404 Can not find: 
/solr/collection1_shard2_replica_n3/update

HTTP ERROR 404
Problem accessing /solr/collection1_shard2_replica_n3/update. Reason:
Can not find: 
/solr/collection1_shard2_replica_n3/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605




at 
__randomizedtesting.SeedInfo.seed([E40262B588F8A56C:1CC49B801BE13DA4]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:551)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1016)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:237)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testVersionsAreReturned(CloudSolrClientTest.java:725)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-12856) Improve javadocs for public SolrJ classes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656108#comment-16656108
 ] 

ASF subversion and git services commented on SOLR-12856:


Commit e6f6f352cfc30517235822b3deed83df1ee144c6 in lucene-solr's branch 
refs/heads/jira/http2 from [~gerlowskija]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e6f6f35 ]

SOLR-12856: Small improvements to SolrJ javadocs


> Improve javadocs for public SolrJ classes
> -
>
> Key: SOLR-12856
> URL: https://issues.apache.org/jira/browse/SOLR-12856
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, SolrJ
>Affects Versions: 7.5
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Fix For: 7.6, master (8.0)
>
> Attachments: SOLR-12856.patch
>
>
> While poking around some SolrJ code, I noticed that the Javadoc documentation 
> tends to be spotty.  Some sections have pretty meticulous descriptions, 
> others are missing javadocs entirely.
> I'm not aiming to entirely correct that situation here, but I did want to fix 
> a few of the more serious concerns I ran into in some of my digging.  This 
> list includes:
> * SolrClient.commit should have some warning about the downside of invoking 
> commits on the client side
> * ditto re: SolrClient.rollback
> * SolrClient's single-doc add method should have a warning about performance 
> implications of not batching.  Not sure if this should live in SolrClient 
> itself and be worded as a "potential" perf impact, or live in each of the 
> clients it applies to.
> * the SolrClient builders can use some clarification around when particular 
> settings are useful.
> * ResponseParser and some other classes might benefit from some high level 
> class javadocs.
> Figured this was worth a JIRA so others can catch potential mistakes I'm 
> making here, or suggest other SolrJ things that'd really benefit from 
> Javadocs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12740) Deprecate rule based replica placement strategy

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656104#comment-16656104
 ] 

ASF subversion and git services commented on SOLR-12740:


Commit 635d1ea53590d6ac25f93779b85d32bc3e5a1500 in lucene-solr's branch 
refs/heads/jira/http2 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=635d1ea ]

SOLR-12740: fixed doc asciidoc errors


> Deprecate rule based replica placement strategy
> ---
>
> Key: SOLR-12740
> URL: https://issues.apache.org/jira/browse/SOLR-12740
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.6, master (8.0)
>
> Attachments: SOLR-12740.patch
>
>
> We should officially mark rule based replica placement strategy as 
> deprecated. This will involve 
> # Creating a ref guide document to help migrate users to the policy rule 
> syntax
> # Return a deprecation warning in create collection API if rules parameter is 
> used



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-6572) Highlighter depends on analyzers-common

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656105#comment-16656105
 ] 

ASF subversion and git services commented on LUCENE-6572:
-

Commit 11a1b8c1a8fdca9f6314bd61695345737309b630 in lucene-solr's branch 
refs/heads/jira/http2 from [~simonw]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=11a1b8c ]

LUCENE-6572: Remove dependency on analyzer-common from highlighing

This makes a simplifed copy of LimitTokenOffsetFilter to the highlighting
module to detach the dependency on analyzer-common.


> Highlighter depends on analyzers-common
> ---
>
> Key: LUCENE-6572
> URL: https://issues.apache.org/jira/browse/LUCENE-6572
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/highlighter
>Reporter: Robert Muir
>Assignee: Simon Willnauer
>Priority: Blocker
> Fix For: master (8.0)
>
> Attachments: LUCENE-6572.patch, LUCENE-6572.patch
>
>
> This is a huge WTF, just for "LimitTokenOffsetFilter" which is only useful 
> for highlighting.
> Adding all these intermodule dependencies makes things too hard to use.
> This is a 5.3 release blocker.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12423) Upgrade to Tika 1.19.1 when available

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656106#comment-16656106
 ] 

ASF subversion and git services commented on SOLR-12423:


Commit fc886497de6edc967852a8ba7cb28f3af9b9fc64 in lucene-solr's branch 
refs/heads/jira/http2 from [~cp.erick...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fc88649 ]

SOLR-12423: Upgrade to Tika 1.19.1 when available. Fixes #468


> Upgrade to Tika 1.19.1 when available
> -
>
> Key: SOLR-12423
> URL: https://issues.apache.org/jira/browse/SOLR-12423
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tim Allison
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.6, master (8.0)
>
> Attachments: SOLR-12423.patch
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> In Tika 1.19, there will be the ability to call the ForkParser and specify a 
> directory of jars from which to load the classes for the Parser in the child 
> processes. This will allow us to remove all of the parser dependencies from 
> Solr. We’ll still need tika-core, of course, but we could drop tika-app.jar 
> in the child process’ bin directory and be done with the upgrade... no more 
> fiddly dependency upgrades and threat of jar hell.
> The ForkParser also protects against ooms, infinite loops and jvm crashes. 
> W00t!
> This issue covers the basic upgrading to 1.19.1.  For the migration to the 
> ForkParser, see SOLR-11721.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12874) Java 9+ GC Log files are being rotated every 20KB instead of every 20MB

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656107#comment-16656107
 ] 

ASF subversion and git services commented on SOLR-12874:


Commit 4b2136eb3c8890999aee6c063e66d577367fa333 in lucene-solr's branch 
refs/heads/jira/http2 from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4b2136e ]

SOLR-12874: Java 9+ GC Logging filesize parameter should use a unit
(merge branch 'java9plus_gc_logging_filesize' of 
https://github.com/tpunder/lucene-solr); this closes #470


> Java 9+ GC Log files are being rotated every 20KB instead of every 20MB
> ---
>
> Key: SOLR-12874
> URL: https://issues.apache.org/jira/browse/SOLR-12874
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.5
>Reporter: Tim Underwood
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 7.6, master (8.0)
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The Java 9+ GC logging options in bin/solr and bin/solr.cmd specify a log 
> rotation file size of 2 which according to JEP 158 
> ([https://openjdk.java.net/jeps/158]) should be the "file size in kb" however 
> when running Solr on Java 11 I'm seeing GC logs rotated every 20KB.
> Changing "filesize=2" to "filesize=20M" fixes the problem for me under 
> Linux.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-Tests-7.x - Build # 959 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/959/

2 tests failed.
FAILED:  
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testVersionsAreReturned

Error Message:
Error from server at http://127.0.0.1:36283/solr/collection1_shard2_replica_n3: 
Expected mime type application/octet-stream but got text/html.   
 
Error 404 Can not find: 
/solr/collection1_shard2_replica_n3/update  HTTP ERROR 
404 Problem accessing /solr/collection1_shard2_replica_n3/update. 
Reason: Can not find: 
/solr/collection1_shard2_replica_n3/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605  
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:36283/solr/collection1_shard2_replica_n3: Expected 
mime type application/octet-stream but got text/html. 


Error 404 Can not find: 
/solr/collection1_shard2_replica_n3/update

HTTP ERROR 404
Problem accessing /solr/collection1_shard2_replica_n3/update. Reason:
Can not find: 
/solr/collection1_shard2_replica_n3/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605




at 
__randomizedtesting.SeedInfo.seed([93AB6250AB6C877E:6B6D9B6538751FB6]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:551)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1016)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:237)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testVersionsAreReturned(CloudSolrClientTest.java:725)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-10981) Allow update to load gzip files

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656061#comment-16656061
 ] 

ASF subversion and git services commented on SOLR-10981:


Commit 2f61f96bfae9d97e3536305e49865433e28737c2 in lucene-solr's branch 
refs/heads/branch_7x from [~lundgren]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2f61f96 ]

SOLR-10981: Support for stream.url or stream.file pointing to gzipped data

(cherry picked from commit 1a8188d92b8148f2d937bd038f48f103526fcbcc)


> Allow update to load gzip files 
> 
>
> Key: SOLR-10981
> URL: https://issues.apache.org/jira/browse/SOLR-10981
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.6
>Reporter: Andrew Lundgren
>Assignee: David Smiley
>Priority: Major
>  Labels: patch
> Fix For: 7.6, master (8.0)
>
> Attachments: SOLR-10981.patch, SOLR-10981.patch, SOLR-10981.patch, 
> SOLR-10981.patch, SOLR-10981.patch, SOLR-10981.patch
>
>
> We currently import large CSV files. We store them in gzip files as they 
> compress at around 80%.
> To import them we must gunzip them and then import them. After that we no 
> longer need the decompressed files.
> This patch allows directly opening either URL, or local files that are 
> gzipped.
> For URLs, to determine if the file is gzipped, it will check the content 
> encoding=="gzip" or if the file ends in ".gz"
> For files, if the file ends in ".gz" then it will assume the file is gzipped.
> I have tested the patch with 4.10.4, 6.6.0, 7.0.1 and master from git.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-7875) Rename or move most of MultiFields

[David Smiley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated LUCENE-7875:
-
Description: 
MultiFields.java has a bunch of static methods that provide a single 
LeafReader's view over a bunch of things.

This goes to MultiBits (which will become public):
 * {{Bits getLiveDocs(IndexReader reader)}}

These go to FieldInfos:
 * {{FieldInfos getMergedFieldInfos(IndexReader reader)}}
 * {{Collection getIndexedFields(IndexReader reader)}}

These go to MultiTerms:
 * Terms getTerms(IndexReader r, String field)
 * {{PostingsEnum getTermPostingsEnum(IndexReader r, String field, BytesRef 
term)}} which is renamed a little

  was:
MultiFields.java has a bunch of static methods that provide a single 
LeafReader's view over a bunch of things.

These could perhaps go to ReaderUtil:
* {{Bits getLiveDocs(IndexReader reader)}}
* {{FieldInfos getMergedFieldInfos(IndexReader reader)}} (removing "Merged" in 
its name which seems inconsistent, or replace with "Multi")

These could perhaps go to MultiTerms:
* {{Collection getIndexedFields(IndexReader reader)}}
* {{Terms getTerms(IndexReader r, String field)}}
* {{PostingsEnum getTermDocsEnum(IndexReader r, String field, BytesRef term)}}

Finally, the MultiFields instance itself, implementing {{Fields}} along with 
the static utility method {{Fields getFields(IndexReader reader)}} could 
perhaps remain until we can finally remove it (or move to a test classpath or 
something) when there is no more purpose for Fields.java.


> Rename or move most of MultiFields
> --
>
> Key: LUCENE-7875
> URL: https://issues.apache.org/jira/browse/LUCENE-7875
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: master (8.0)
>
> Attachments: LUCENE-7875.patch, LUCENE-7875.patch, LUCENE-7875.patch, 
> LUCENE-7875.patch
>
>
> MultiFields.java has a bunch of static methods that provide a single 
> LeafReader's view over a bunch of things.
> This goes to MultiBits (which will become public):
>  * {{Bits getLiveDocs(IndexReader reader)}}
> These go to FieldInfos:
>  * {{FieldInfos getMergedFieldInfos(IndexReader reader)}}
>  * {{Collection getIndexedFields(IndexReader reader)}}
> These go to MultiTerms:
>  * Terms getTerms(IndexReader r, String field)
>  * {{PostingsEnum getTermPostingsEnum(IndexReader r, String field, BytesRef 
> term)}} which is renamed a little



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10981) Allow update to load gzip files

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656049#comment-16656049
 ] 

ASF subversion and git services commented on SOLR-10981:


Commit 1a8188d92b8148f2d937bd038f48f103526fcbcc in lucene-solr's branch 
refs/heads/master from [~lundgren]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1a8188d ]

SOLR-10981: Support for stream.url or stream.file pointing to gzipped data


> Allow update to load gzip files 
> 
>
> Key: SOLR-10981
> URL: https://issues.apache.org/jira/browse/SOLR-10981
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.6
>Reporter: Andrew Lundgren
>Assignee: David Smiley
>Priority: Major
>  Labels: patch
> Fix For: 7.6, master (8.0)
>
> Attachments: SOLR-10981.patch, SOLR-10981.patch, SOLR-10981.patch, 
> SOLR-10981.patch, SOLR-10981.patch, SOLR-10981.patch
>
>
> We currently import large CSV files. We store them in gzip files as they 
> compress at around 80%.
> To import them we must gunzip them and then import them. After that we no 
> longer need the decompressed files.
> This patch allows directly opening either URL, or local files that are 
> gzipped.
> For URLs, to determine if the file is gzipped, it will check the content 
> encoding=="gzip" or if the file ends in ".gz"
> For files, if the file ends in ".gz" then it will assume the file is gzipped.
> I have tested the patch with 4.10.4, 6.6.0, 7.0.1 and master from git.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7875) Rename or move most of MultiFields

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656045#comment-16656045
 ] 

ASF subversion and git services commented on LUCENE-7875:
-

Commit fd9164801e703b278922dae6cc3c53e0578fa1d6 in lucene-solr's branch 
refs/heads/master from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fd91648 ]

LUCENE-7875: Moved MultiFields static methods to MultiTerms, FieldInfos and 
MultiBits.
MultiBits is now public and has getLiveDocs.


> Rename or move most of MultiFields
> --
>
> Key: LUCENE-7875
> URL: https://issues.apache.org/jira/browse/LUCENE-7875
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: master (8.0)
>
> Attachments: LUCENE-7875.patch, LUCENE-7875.patch, LUCENE-7875.patch, 
> LUCENE-7875.patch
>
>
> MultiFields.java has a bunch of static methods that provide a single 
> LeafReader's view over a bunch of things.
> These could perhaps go to ReaderUtil:
> * {{Bits getLiveDocs(IndexReader reader)}}
> * {{FieldInfos getMergedFieldInfos(IndexReader reader)}} (removing "Merged" 
> in its name which seems inconsistent, or replace with "Multi")
> These could perhaps go to MultiTerms:
> * {{Collection getIndexedFields(IndexReader reader)}}
> * {{Terms getTerms(IndexReader r, String field)}}
> * {{PostingsEnum getTermDocsEnum(IndexReader r, String field, BytesRef term)}}
> Finally, the MultiFields instance itself, implementing {{Fields}} along with 
> the static utility method {{Fields getFields(IndexReader reader)}} could 
> perhaps remain until we can finally remove it (or move to a test classpath or 
> something) when there is no more purpose for Fields.java.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_172) - Build # 2937 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2937/
Java: 32bit/jdk1.8.0_172 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.client.solrj.impl.CloudSolrClientTest.testRouting

Error Message:
Error from server at 
https://127.0.0.1:37309/solr/collection1_shard2_replica_n3: Expected mime type 
application/octet-stream but got text/html.Error 404 
Can not find: /solr/collection1_shard2_replica_n3/update  
HTTP ERROR 404 Problem accessing 
/solr/collection1_shard2_replica_n3/update. Reason: Can not find: 
/solr/collection1_shard2_replica_n3/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605  
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at https://127.0.0.1:37309/solr/collection1_shard2_replica_n3: Expected 
mime type application/octet-stream but got text/html. 


Error 404 Can not find: 
/solr/collection1_shard2_replica_n3/update

HTTP ERROR 404
Problem accessing /solr/collection1_shard2_replica_n3/update. Reason:
Can not find: 
/solr/collection1_shard2_replica_n3/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605




at 
__randomizedtesting.SeedInfo.seed([5A9E8D377AA8397F:9829B15F79E8C907]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:551)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1016)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testRouting(CloudSolrClientTest.java:238)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 

[jira] [Updated] (SOLR-12884) Admin UI, admin/luke and *Point fields

[Erick Erickson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson updated SOLR-12884:
--
Summary: Admin UI, admin/luke and *Point fields  (was: Admin UI and *Point 
fields)

> Admin UI, admin/luke and *Point fields
> --
>
> Key: SOLR-12884
> URL: https://issues.apache.org/jira/browse/SOLR-12884
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (8.0)
>Reporter: Erick Erickson
>Priority: Major
>
> One of the conference attendees noted that you go to the schema browser and 
> click on, say, a pint field, then click "load term info", nothing is shown.
> admin/luke similarly doesn't show much interesting, here's the response for a 
> pint .vs. a tint field:
> "popularity":\{ "type":"pint", "schema":"I-SD-OF--"},
> "popularityt":{ "type":"tint", "schema":"I-S--OF--",
>                        "index":"-TS--", "docs":15},
>  
> What, if anything, should we do in these two cases? Since  the points-based 
> numerics don't have terms like Trie* fields, I don't think we _can_ show much 
> more so the above makes sense, it's just jarring to end users and looks like 
> a bug.
> WDYT about putting in some useful information though. Say for the Admin UI 
> for points-based "terms cannot be shown for points-based fields" or some such?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 350 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/350/

1 tests failed.
FAILED:  org.apache.solr.client.solrj.impl.CloudSolrClientTest.testRouting

Error Message:
Error from server at http://127.0.0.1:36410/solr/collection1_shard2_replica_n2: 
Expected mime type application/octet-stream but got text/html.   
 
Error 404 Can not find: 
/solr/collection1_shard2_replica_n2/update  HTTP ERROR 
404 Problem accessing /solr/collection1_shard2_replica_n2/update. 
Reason: Can not find: 
/solr/collection1_shard2_replica_n2/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605  
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:36410/solr/collection1_shard2_replica_n2: Expected 
mime type application/octet-stream but got text/html. 


Error 404 Can not find: 
/solr/collection1_shard2_replica_n2/update

HTTP ERROR 404
Problem accessing /solr/collection1_shard2_replica_n2/update. Reason:
Can not find: 
/solr/collection1_shard2_replica_n2/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.11.v20180605




at 
__randomizedtesting.SeedInfo.seed([B050E0AF0C6B0B20:72E7DCC70F2BFB58]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:551)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1016)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:949)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:237)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testRouting(CloudSolrClientTest.java:269)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Resolved] (SOLR-12876) un-BadApple ShardParamsTest.testGetShardsTolerantAsBool

[Christine Poerschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christine Poerschke resolved SOLR-12876.

   Resolution: Fixed
Fix Version/s: master (8.0)
   7.6

> un-BadApple ShardParamsTest.testGetShardsTolerantAsBool
> ---
>
> Key: SOLR-12876
> URL: https://issues.apache.org/jira/browse/SOLR-12876
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 7.6, master (8.0)
>
>
> I reviewed the test itself and searched the mailing list archive for failures 
> in the last 3 years via 
> https://lists.apache.org/list.html?dev@lucene.apache.org:lte=3y:ShardParamsTest.testGetShardsTolerantAsBool
>  (and found no examples there but did not look elsewhere) and based on that I 
> think the test can be un-BadApple-d.
> A small change
> {code}
> - assertTrue(exception.getMessage().startsWith("invalid boolean value: "));
> + assertTrue(exception.getMessage(), 
> exception.getMessage().startsWith("invalid boolean value: "));
> {code}
> might also be helpful. And {{ant beast}} ing of course too.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12877) reduce test failures due to NullPointerException

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655967#comment-16655967
 ] 

ASF subversion and git services commented on SOLR-12877:


Commit 4d811b798976e3213737ffdccd4540e40218d837 in lucene-solr's branch 
refs/heads/branch_7x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4d811b7 ]

SOLR-12877: avoid NPE in TestUtilizeNode.getReplicaList


> reduce test failures due to NullPointerException
> 
>
> Key: SOLR-12877
> URL: https://issues.apache.org/jira/browse/SOLR-12877
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Priority: Minor
>
> Creating this as an umbrella ticket for fixing various NullPointerExceptions 
> e.g. encounted in this type of code pattern in tests:
> before:
> {code:java}
> Bar bar = foo.getBar(id);
> assertEquals(42, bar.size()); // if bar is null we hit a NPE here
> {code}
> after:
> {code:java}
> Bar bar = foo.getBar(id);
> assertNotNull(bar); // if bar is null the test now fails here
> assertEquals(42, bar.size());
> {code}
> The test failure itself would still remain a test failure but a slightly 
> clearer one perhaps.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12877) reduce test failures due to NullPointerException

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655966#comment-16655966
 ] 

ASF subversion and git services commented on SOLR-12877:


Commit ac60ddda3c96584ebcca35660d846ab6424ea680 in lucene-solr's branch 
refs/heads/branch_7x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ac60ddd ]

SOLR-12877: avoid NPE in TestTlogReplica.testRealTimeGet


> reduce test failures due to NullPointerException
> 
>
> Key: SOLR-12877
> URL: https://issues.apache.org/jira/browse/SOLR-12877
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Priority: Minor
>
> Creating this as an umbrella ticket for fixing various NullPointerExceptions 
> e.g. encounted in this type of code pattern in tests:
> before:
> {code:java}
> Bar bar = foo.getBar(id);
> assertEquals(42, bar.size()); // if bar is null we hit a NPE here
> {code}
> after:
> {code:java}
> Bar bar = foo.getBar(id);
> assertNotNull(bar); // if bar is null the test now fails here
> assertEquals(42, bar.size());
> {code}
> The test failure itself would still remain a test failure but a slightly 
> clearer one perhaps.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12876) un-BadApple ShardParamsTest.testGetShardsTolerantAsBool

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655965#comment-16655965
 ] 

ASF subversion and git services commented on SOLR-12876:


Commit 3e874f7dcea462f85adc66a208aa19e6b874562f in lucene-solr's branch 
refs/heads/branch_7x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3e874f7 ]

SOLR-12876: remove @BadApple from ShardParamsTest.testGetShardsTolerantAsBool


> un-BadApple ShardParamsTest.testGetShardsTolerantAsBool
> ---
>
> Key: SOLR-12876
> URL: https://issues.apache.org/jira/browse/SOLR-12876
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> I reviewed the test itself and searched the mailing list archive for failures 
> in the last 3 years via 
> https://lists.apache.org/list.html?dev@lucene.apache.org:lte=3y:ShardParamsTest.testGetShardsTolerantAsBool
>  (and found no examples there but did not look elsewhere) and based on that I 
> think the test can be un-BadApple-d.
> A small change
> {code}
> - assertTrue(exception.getMessage().startsWith("invalid boolean value: "));
> + assertTrue(exception.getMessage(), 
> exception.getMessage().startsWith("invalid boolean value: "));
> {code}
> might also be helpful. And {{ant beast}} ing of course too.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12876) un-BadApple ShardParamsTest.testGetShardsTolerantAsBool

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655964#comment-16655964
 ] 

ASF subversion and git services commented on SOLR-12876:


Commit 1643df49d081ea5ed328463acb3238bda2d42878 in lucene-solr's branch 
refs/heads/branch_7x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1643df4 ]

SOLR-12876: upon failure report exception message in 
ShardParamsTest.testGetShardsTolerantAsBool


> un-BadApple ShardParamsTest.testGetShardsTolerantAsBool
> ---
>
> Key: SOLR-12876
> URL: https://issues.apache.org/jira/browse/SOLR-12876
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> I reviewed the test itself and searched the mailing list archive for failures 
> in the last 3 years via 
> https://lists.apache.org/list.html?dev@lucene.apache.org:lte=3y:ShardParamsTest.testGetShardsTolerantAsBool
>  (and found no examples there but did not look elsewhere) and based on that I 
> think the test can be un-BadApple-d.
> A small change
> {code}
> - assertTrue(exception.getMessage().startsWith("invalid boolean value: "));
> + assertTrue(exception.getMessage(), 
> exception.getMessage().startsWith("invalid boolean value: "));
> {code}
> might also be helpful. And {{ant beast}} ing of course too.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-12884) Admin UI and *Point fields

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-12884:
-

 Summary: Admin UI and *Point fields
 Key: SOLR-12884
 URL: https://issues.apache.org/jira/browse/SOLR-12884
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: master (8.0)
Reporter: Erick Erickson


One of the conference attendees noted that you go to the schema browser and 
click on, say, a pint field, then click "load term info", nothing is shown.

admin/luke similarly doesn't show much interesting, here's the response for a 
pint .vs. a tint field:

"popularity":\{ "type":"pint", "schema":"I-SD-OF--"},

"popularityt":{ "type":"tint", "schema":"I-S--OF--",

                       "index":"-TS--", "docs":15},

 

What, if anything, should we do in these two cases? Since  the points-based 
numerics don't have terms like Trie* fields, I don't think we _can_ show much 
more so the above makes sense, it's just jarring to end users and looks like a 
bug.

WDYT about putting in some useful information though. Say for the Admin UI for 
points-based "terms cannot be shown for points-based fields" or some such?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12876) un-BadApple ShardParamsTest.testGetShardsTolerantAsBool

[Christine Poerschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655943#comment-16655943
 ] 

Christine Poerschke commented on SOLR-12876:


Thanks [~erickerickson] for the input! Of course, if the failures return then 
re-BadApple'ing could be on the cards. And in case it is the last assert that 
fails then with the first commit above we'd have more exception details to 
debug from too.

> un-BadApple ShardParamsTest.testGetShardsTolerantAsBool
> ---
>
> Key: SOLR-12876
> URL: https://issues.apache.org/jira/browse/SOLR-12876
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> I reviewed the test itself and searched the mailing list archive for failures 
> in the last 3 years via 
> https://lists.apache.org/list.html?dev@lucene.apache.org:lte=3y:ShardParamsTest.testGetShardsTolerantAsBool
>  (and found no examples there but did not look elsewhere) and based on that I 
> think the test can be un-BadApple-d.
> A small change
> {code}
> - assertTrue(exception.getMessage().startsWith("invalid boolean value: "));
> + assertTrue(exception.getMessage(), 
> exception.getMessage().startsWith("invalid boolean value: "));
> {code}
> might also be helpful. And {{ant beast}} ing of course too.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Lucene/Solr 8.0

[David Smiley]

+1 to a 7.6 —lots of stuff in there
On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize  wrote:

> If we're planning to postpone cutting an 8.0 branch until a few weeks from
> now then I'd like to propose (and volunteer to RM) a 7.6 release targeted
> for late November or early December (following the typical 2 month release
> pattern). It feels like this might give a little breathing room for
> finishing up 8.0 blockers? And looking at the change log there appear to be
> a healthy list of features, bug fixes, and improvements to both Solr and
> Lucene that warrant a 7.6 release? Personally I wouldn't mind releasing the
> LatLonShape encoding changes in LUCENE-8521
>  and selective
> indexing work done in LUCENE-8496
> . Any objections or
> thoughts?
>
> - Nick
>
>
> On Thu, Oct 18, 2018 at 5:32 AM Đạt Cao Mạnh 
> wrote:
>
>> Thanks Cassandra and Jim,
>>
>> I created a blocker issue for Solr 8.0 SOLR-12883
>> , currently in
>> jira/http2 branch there are a draft-unmature implementation of SPNEGO
>> authentication which enough to makes the test pass, this implementation
>> will be removed when SOLR-12883 gets resolved . Therefore I don't see any
>> problem on merging jira/http2 to master branch in the next week.
>>
>> On Thu, Oct 18, 2018 at 2:33 AM jim ferenczi 
>> wrote:
>>
>>> > But if you're working with a different assumption - that just the
>>> existence of the branch does not stop Dat from still merging his work and
>>> the work being included in 8.0 - then I agree, waiting for him to merge
>>> doesn't need to stop the creation of the branch.
>>>
>>> Yes that's my reasoning. This issue is a blocker so we won't release
>>> without it but we can work on the branch in the meantime and let other
>>> people work on new features that are not targeted to 8.
>>>
>>> Le mer. 17 oct. 2018 à 20:51, Cassandra Targett 
>>> a écrit :
>>>
 OK - I was making an assumption that the timeline for the first 8.0 RC
 would be ASAP after the branch is created.

 It's a common perception that making a branch freezes adding new
 features to the release, perhaps in an unofficial way (more of a courtesy
 rather than a rule). But if you're working with a different assumption -
 that just the existence of the branch does not stop Dat from still merging
 his work and the work being included in 8.0 - then I agree, waiting for him
 to merge doesn't need to stop the creation of the branch.

 If, however, once the branch is there people object to Dat merging his
 work because it's "too late", then the branch shouldn't be created yet
 because we want to really try to clear that blocker for 8.0.

 Cassandra

 On Wed, Oct 17, 2018 at 12:13 PM jim ferenczi 
 wrote:

> Ok thanks for answering.
>
> > - I think Solr needs a couple more weeks since the work Dat is doing
> isn't quite done yet.
>
> We can wait a few more weeks to create the branch but I don't think
> that one action (creating the branch) prevents the other (the work Dat is
> doing).
> HTTP/2 is one of the blocker for the release but it can be done in
> master and backported to the appropriate branch as any other feature ? We
> just need an issue with the blocker label to ensure that
> we don't miss it ;). Creating the branch early would also help in case
> you don't want to release all the work at once in 8.0.0.
> Next week was just a proposal, what I meant was soon because we target
> a release in a few months.
>
>
> Le mer. 17 oct. 2018 à 17:52, Cassandra Targett 
> a écrit :
>
>> IMO next week is a bit too soon for the branch - I think Solr needs a
>> couple more weeks since the work Dat is doing isn't quite done yet.
>>
>> Solr needs the HTTP/2 work Dat has been doing, and he told me
>> yesterday he feels it is nearly ready to be merged into master. However, 
>> it
>> does require a new release of Jetty to Solr is able to retain Kerberos
>> authentication support (Dat has been working with that team to help test
>> the changes Jetty needs to support Kerberos with HTTP/2). They should get
>> that release out soon, but we are dependent on them a little bit.
>>
>> He can hopefully reply with more details on his status and what else
>> needs to be done.
>>
>> Once Dat merges his work, IMO we should leave it in master for a
>> little bit. While he has been beasting and testing with Jenkins as he 
>> goes
>> along, I think it would be good to have all the regular master builds 
>> work
>> on it for a little bit also.
>>
>> Of the other blockers, the only other large-ish one is to fully
>> remove Trie* fields, which some of us also discussed yesterday and it
>> seemed we concluded that 

[jira] [Resolved] (SOLR-12856) Improve javadocs for public SolrJ classes

[Jason Gerlowski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Gerlowski resolved SOLR-12856.

   Resolution: Fixed
Fix Version/s: master (8.0)
   7.6

I opened this up to fix/add Javadocs in a few specific places.  I've committed 
those, though there's certainly other low-hanging fruit out there that I'd like 
to get to (or see others get to) soon, but that should really probably be in 
its own JIRA if/when those get raised.

Closing this out

> Improve javadocs for public SolrJ classes
> -
>
> Key: SOLR-12856
> URL: https://issues.apache.org/jira/browse/SOLR-12856
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, SolrJ
>Affects Versions: 7.5
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Fix For: 7.6, master (8.0)
>
> Attachments: SOLR-12856.patch
>
>
> While poking around some SolrJ code, I noticed that the Javadoc documentation 
> tends to be spotty.  Some sections have pretty meticulous descriptions, 
> others are missing javadocs entirely.
> I'm not aiming to entirely correct that situation here, but I did want to fix 
> a few of the more serious concerns I ran into in some of my digging.  This 
> list includes:
> * SolrClient.commit should have some warning about the downside of invoking 
> commits on the client side
> * ditto re: SolrClient.rollback
> * SolrClient's single-doc add method should have a warning about performance 
> implications of not batching.  Not sure if this should live in SolrClient 
> itself and be worded as a "potential" perf impact, or live in each of the 
> clients it applies to.
> * the SolrClient builders can use some clarification around when particular 
> settings are useful.
> * ResponseParser and some other classes might benefit from some high level 
> class javadocs.
> Figured this was worth a JIRA so others can catch potential mistakes I'm 
> making here, or suggest other SolrJ things that'd really benefit from 
> Javadocs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12746) Ref Guide HTML output should adhere to more standard HTML5

[Cassandra Targett (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655875#comment-16655875
 ] 

Cassandra Targett commented on SOLR-12746:
--

Based on feedback I got from the Asciidoctor community, this error I mentioned 
as the #2 caveat earlier:

bq. There is an error output by the Slim engine ({{Slim::Engine: Option 
:asciidoc is invalid}}) during the HTML build for every template (so, 30+ 
times).

is resolved by downgrading the Slim version to v3.0 instead of 4.0.1 which I'd 
installed as the latest since the templates didn't specify any specific 
version. I don't think we care about the Slim version, so I can update the 
README and Jenkins scripts to force this version and we can call that problem 
resolved.

I found some more CSS changes to fix & still a TODO or two I'd mentioned 
earlier, so I'll update the branch with these changes as soon as I can (next 
week).

> Ref Guide HTML output should adhere to more standard HTML5
> --
>
> Key: SOLR-12746
> URL: https://issues.apache.org/jira/browse/SOLR-12746
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Major
>
> The default HTML produced by Jekyll/Asciidoctor adds a lot of extra {{}} 
> tags to the content which break up our content into very small chunks. This 
> is acceptable to a casual website reader as far as it goes, but any Reader 
> view in a browser or another type of content extraction system that uses a 
> similar "readability" scoring algorithm is going to either miss a lot of 
> content or fail to display the page entirely.
> To see what I mean, take a page like 
> https://lucene.apache.org/solr/guide/7_4/language-analysis.html and enable 
> Reader View in your browser (I used Firefox; Steve Rowe told me offline 
> Safari would not even offer the option on the page for him). You will notice 
> a lot of missing content. It's almost like someone selected sentences at 
> random.
> Asciidoctor has a long-standing issue to provide a better more 
> semantic-oriented HTML5 output, but it has not been resolved yet: 
> https://github.com/asciidoctor/asciidoctor/issues/242
> Asciidoctor does provide a way to override the default output templates by 
> providing your own in Slim, HAML, ERB or any other template language 
> supported by Tilt (none of which I know yet). There are some samples 
> available via the Asciidoctor project which we can borrow, but it's otherwise 
> unknown as of yet what parts of the output are causing the worst of the 
> problems. This issue is to explore how to fix it to improve this part of the 
> HTML reading experience.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-10.0.1) - Build # 23052 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23052/
Java: 64bit/jdk-10.0.1 -XX:+UseCompressedOops -XX:+UseSerialGC

8 tests failed.
FAILED:  
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica

Error Message:
Expected new active leader null Live Nodes: [127.0.0.1:36029_solr, 
127.0.0.1:39547_solr, 127.0.0.1:41717_solr] Last available state: 
DocCollection(raceDeleteReplica_false//collections/raceDeleteReplica_false/state.json/11)={
   "pullReplicas":"0",   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node4":{   "core":"raceDeleteReplica_false_shard1_replica_n2",
   "base_url":"https://127.0.0.1:42113/solr;,   
"node_name":"127.0.0.1:42113_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false",   "leader":"true"},  
   "core_node6":{   
"core":"raceDeleteReplica_false_shard1_replica_n5",   
"base_url":"https://127.0.0.1:42113/solr;,   
"node_name":"127.0.0.1:42113_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"1",   
"autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: Expected new active leader
null
Live Nodes: [127.0.0.1:36029_solr, 127.0.0.1:39547_solr, 127.0.0.1:41717_solr]
Last available state: 
DocCollection(raceDeleteReplica_false//collections/raceDeleteReplica_false/state.json/11)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node4":{
  "core":"raceDeleteReplica_false_shard1_replica_n2",
  "base_url":"https://127.0.0.1:42113/solr;,
  "node_name":"127.0.0.1:42113_solr",
  "state":"down",
  "type":"NRT",
  "force_set_state":"false",
  "leader":"true"},
"core_node6":{
  "core":"raceDeleteReplica_false_shard1_replica_n5",
  "base_url":"https://127.0.0.1:42113/solr;,
  "node_name":"127.0.0.1:42113_solr",
  "state":"down",
  "type":"NRT",
  "force_set_state":"false",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([FDF2937507D55AAC:97E4F2A56F271066]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:280)
at 
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:328)
at 
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:224)
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:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at 

Re: Lucene/Solr 8.0

[Nicholas Knize]

If we're planning to postpone cutting an 8.0 branch until a few weeks from
now then I'd like to propose (and volunteer to RM) a 7.6 release targeted
for late November or early December (following the typical 2 month release
pattern). It feels like this might give a little breathing room for
finishing up 8.0 blockers? And looking at the change log there appear to be
a healthy list of features, bug fixes, and improvements to both Solr and
Lucene that warrant a 7.6 release? Personally I wouldn't mind releasing the
LatLonShape encoding changes in LUCENE-8521
 and selective indexing
work done in LUCENE-8496 .
Any objections or thoughts?

- Nick


On Thu, Oct 18, 2018 at 5:32 AM Đạt Cao Mạnh 
wrote:

> Thanks Cassandra and Jim,
>
> I created a blocker issue for Solr 8.0 SOLR-12883
> , currently in
> jira/http2 branch there are a draft-unmature implementation of SPNEGO
> authentication which enough to makes the test pass, this implementation
> will be removed when SOLR-12883 gets resolved . Therefore I don't see any
> problem on merging jira/http2 to master branch in the next week.
>
> On Thu, Oct 18, 2018 at 2:33 AM jim ferenczi 
> wrote:
>
>> > But if you're working with a different assumption - that just the
>> existence of the branch does not stop Dat from still merging his work and
>> the work being included in 8.0 - then I agree, waiting for him to merge
>> doesn't need to stop the creation of the branch.
>>
>> Yes that's my reasoning. This issue is a blocker so we won't release
>> without it but we can work on the branch in the meantime and let other
>> people work on new features that are not targeted to 8.
>>
>> Le mer. 17 oct. 2018 à 20:51, Cassandra Targett 
>> a écrit :
>>
>>> OK - I was making an assumption that the timeline for the first 8.0 RC
>>> would be ASAP after the branch is created.
>>>
>>> It's a common perception that making a branch freezes adding new
>>> features to the release, perhaps in an unofficial way (more of a courtesy
>>> rather than a rule). But if you're working with a different assumption -
>>> that just the existence of the branch does not stop Dat from still merging
>>> his work and the work being included in 8.0 - then I agree, waiting for him
>>> to merge doesn't need to stop the creation of the branch.
>>>
>>> If, however, once the branch is there people object to Dat merging his
>>> work because it's "too late", then the branch shouldn't be created yet
>>> because we want to really try to clear that blocker for 8.0.
>>>
>>> Cassandra
>>>
>>> On Wed, Oct 17, 2018 at 12:13 PM jim ferenczi 
>>> wrote:
>>>
 Ok thanks for answering.

 > - I think Solr needs a couple more weeks since the work Dat is doing
 isn't quite done yet.

 We can wait a few more weeks to create the branch but I don't think
 that one action (creating the branch) prevents the other (the work Dat is
 doing).
 HTTP/2 is one of the blocker for the release but it can be done in
 master and backported to the appropriate branch as any other feature ? We
 just need an issue with the blocker label to ensure that
 we don't miss it ;). Creating the branch early would also help in case
 you don't want to release all the work at once in 8.0.0.
 Next week was just a proposal, what I meant was soon because we target
 a release in a few months.


 Le mer. 17 oct. 2018 à 17:52, Cassandra Targett 
 a écrit :

> IMO next week is a bit too soon for the branch - I think Solr needs a
> couple more weeks since the work Dat is doing isn't quite done yet.
>
> Solr needs the HTTP/2 work Dat has been doing, and he told me
> yesterday he feels it is nearly ready to be merged into master. However, 
> it
> does require a new release of Jetty to Solr is able to retain Kerberos
> authentication support (Dat has been working with that team to help test
> the changes Jetty needs to support Kerberos with HTTP/2). They should get
> that release out soon, but we are dependent on them a little bit.
>
> He can hopefully reply with more details on his status and what else
> needs to be done.
>
> Once Dat merges his work, IMO we should leave it in master for a
> little bit. While he has been beasting and testing with Jenkins as he goes
> along, I think it would be good to have all the regular master builds work
> on it for a little bit also.
>
> Of the other blockers, the only other large-ish one is to fully remove
> Trie* fields, which some of us also discussed yesterday and it seemed we
> concluded that Solr isn't really ready to do that. The performance issues
> with single value lookups are a major obstacle. It would be nice if 
> someone
> with a bit more experience with that could comment in the issue
> 

[jira] [Commented] (SOLR-12881) Remove unneeded import statements

[Peter Somogyi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655737#comment-16655737
 ] 

Peter Somogyi commented on SOLR-12881:
--

The test errors are unrelated because none of them has compilation error caused 
my missing import.

Failure in lucene/tools is also unrelated. I created LUCENE-8537 to fix that 
build problem.

> Remove unneeded import statements
> -
>
> Key: SOLR-12881
> URL: https://issues.apache.org/jira/browse/SOLR-12881
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (8.0)
>Reporter: Peter Somogyi
>Priority: Trivial
> Attachments: SOLR-12881.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There are unnecessary import statements:
>  * import from java.lang
>  * import from same package
>  * unused import



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-8537) ant test command fails under lucene/tools

[Peter Somogyi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Somogyi updated LUCENE-8537:
--
Attachment: LUCENE-8537.patch

> ant test command fails under lucene/tools
> -
>
> Key: LUCENE-8537
> URL: https://issues.apache.org/jira/browse/LUCENE-8537
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: master (8.0)
>Reporter: Peter Somogyi
>Priority: Minor
> Attachments: LUCENE-8537.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The {{ant test}} command executed under {{lucene/tools}} folder fails because 
> it does not have {{junit.classpath}} property. Since the module does not have 
> any test folder we could override the {{-test}} and {{-check-totals}} targets.
> {noformat}
> bash-3.2$ pwd
> /Users/peter.somogyi/repos/lucene-solr/lucene/tools
> bash-3.2$ ant test
> Buildfile: /Users/peter.somogyi/repos/lucene-solr/lucene/tools/build.xml
> ...
> -test:
>[junit4]  says ciao! Master seed: 9A2ACC9B4A3C8553
> BUILD FAILED
> /Users/peter.somogyi/repos/lucene-solr/lucene/common-build.xml:1567: The 
> following error occurred while executing this line:
> /Users/peter.somogyi/repos/lucene-solr/lucene/common-build.xml:1092: 
> Reference junit.classpath not found.
> Total time: 1 second
> {noformat}
> I ran into this issue when uploaded a patch where I removed an import from 
> this module. This triggered a module-level build during precommit that failed 
> with this error.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr pull request #481: LUCENE-8537: ant test command fails under luc...

[petersomogyi]

GitHub user petersomogyi opened a pull request:

https://github.com/apache/lucene-solr/pull/481

LUCENE-8537: ant test command fails under lucene/tools



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/petersomogyi/lucene-solr LUCENE-8537

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/481.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #481


commit 9e85b051228d5b56f0ea0612ac815fd843b71b41
Author: Peter Somogyi 
Date:   2018-10-18T18:40:40Z

LUCENE-8537: ant test command fails under lucene/tools




---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8521) Change LatLonShape encoding to use selective indexing

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655728#comment-16655728
 ] 

ASF subversion and git services commented on LUCENE-8521:
-

Commit 2a04115a75c37e45015402f1056207da99fdebd1 in lucene-solr's branch 
refs/heads/branch_7x from [~nknize]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2a04115 ]

LUCENE-8521: Change LatLonShape encoding to use selective indexing

This improvement changes LatLonShape encoding to 7 dimensions instead of 6. The 
first 4 are index dimensions defining the bounding box of the Triangle and the 
remaining 3 data dimensions define the vertices of the triangle.


> Change LatLonShape encoding to use selective indexing
> -
>
> Key: LUCENE-8521
> URL: https://issues.apache.org/jira/browse/LUCENE-8521
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
>Priority: Major
> Attachments: LUCENE-8521.patch
>
>
> LUCENE-8496 allows for selecting the first n dimensions to be used for 
> building the index and the remaining dimensions to be used as data 
> dimensions. This feature changes {{LatLonShape}} encoding to a 7 dimension 
> encoding instead of 6; where the first 4 are index dimensions defining the 
> bounding box of the {{LatLonShape.Triangle}} and the remaining 3 data 
> dimensions defining the vertices of the triangle.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-8537) ant test command fails under lucene/tools

[Peter Somogyi (JIRA)]

Peter Somogyi created LUCENE-8537:
-

 Summary: ant test command fails under lucene/tools
 Key: LUCENE-8537
 URL: https://issues.apache.org/jira/browse/LUCENE-8537
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: master (8.0)
Reporter: Peter Somogyi


The {{ant test}} command executed under {{lucene/tools}} folder fails because 
it does not have {{junit.classpath}} property. Since the module does not have 
any test folder we could override the {{-test}} and {{-check-totals}} targets.
{noformat}
bash-3.2$ pwd
/Users/peter.somogyi/repos/lucene-solr/lucene/tools
bash-3.2$ ant test
Buildfile: /Users/peter.somogyi/repos/lucene-solr/lucene/tools/build.xml
...
-test:
   [junit4]  says ciao! Master seed: 9A2ACC9B4A3C8553

BUILD FAILED
/Users/peter.somogyi/repos/lucene-solr/lucene/common-build.xml:1567: The 
following error occurred while executing this line:
/Users/peter.somogyi/repos/lucene-solr/lucene/common-build.xml:1092: Reference 
junit.classpath not found.

Total time: 1 second
{noformat}
I ran into this issue when uploaded a patch where I removed an import from this 
module. This triggered a module-level build during precommit that failed with 
this error.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_172) - Build # 2936 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2936/
Java: 64bit/jdk1.8.0_172 -XX:+UseCompressedOops -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMixedBounds

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([2A9CAE5AFBA0B490:201F11F7B61BBFCA]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMixedBounds(IndexSizeTriggerTest.java:572)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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)


FAILED:  org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMixedBounds

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 

[jira] [Commented] (LUCENE-8521) Change LatLonShape encoding to use selective indexing

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655713#comment-16655713
 ] 

ASF subversion and git services commented on LUCENE-8521:
-

Commit ed8a395948f406aca7ac55fd3bd0f5348af353c3 in lucene-solr's branch 
refs/heads/master from [~nknize]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ed8a395 ]

LUCENE-8521: Change LatLonShape encoding to use selective indexing

This improvement changes LatLonShape encoding to 7 dimensions instead of 6. The 
first 4 are index dimensions defining the bounding box of the Triangle and the 
remaining 3 data dimensions define the vertices of the triangle.


> Change LatLonShape encoding to use selective indexing
> -
>
> Key: LUCENE-8521
> URL: https://issues.apache.org/jira/browse/LUCENE-8521
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
>Priority: Major
> Attachments: LUCENE-8521.patch
>
>
> LUCENE-8496 allows for selecting the first n dimensions to be used for 
> building the index and the remaining dimensions to be used as data 
> dimensions. This feature changes {{LatLonShape}} encoding to a 7 dimension 
> encoding instead of 6; where the first 4 are index dimensions defining the 
> bounding box of the {{LatLonShape.Triangle}} and the remaining 3 data 
> dimensions defining the vertices of the triangle.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-8507) TopFieldCollector should set minimum competitive score if the primary sort is by relevancy

[Jim Ferenczi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jim Ferenczi resolved LUCENE-8507.
--
   Resolution: Fixed
Fix Version/s: master (8.0)

Thanks Adrien and Alan !

> TopFieldCollector should set minimum competitive score if the primary sort is 
> by relevancy
> --
>
> Key: LUCENE-8507
> URL: https://issues.apache.org/jira/browse/LUCENE-8507
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Jim Ferenczi
>Priority: Minor
> Fix For: master (8.0)
>
> Attachments: LUCENE-8507.patch, LUCENE-8507.patch
>
>
> When the primary sort in the TopFieldCollector is set to relevancy it is 
> possible to update the minimum competitive score like the TopScoreCollector 
> does. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8507) TopFieldCollector should set minimum competitive score if the primary sort is by relevancy

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655628#comment-16655628
 ] 

ASF subversion and git services commented on LUCENE-8507:
-

Commit 947f82679afa6d984c246b686d0133085982c376 in lucene-solr's branch 
refs/heads/master from [~jim.ferenczi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=947f826 ]

LUCENE-8507: TopFieldCollector can now update the minimum competitive score if 
the primary sort is by relevancy and the total hit count is not required.


> TopFieldCollector should set minimum competitive score if the primary sort is 
> by relevancy
> --
>
> Key: LUCENE-8507
> URL: https://issues.apache.org/jira/browse/LUCENE-8507
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Jim Ferenczi
>Priority: Minor
> Attachments: LUCENE-8507.patch, LUCENE-8507.patch
>
>
> When the primary sort in the TopFieldCollector is set to relevancy it is 
> possible to update the minimum competitive score like the TopScoreCollector 
> does. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12881) Remove unneeded import statements

[Lucene/Solr QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655606#comment-16655606
 ] 

Lucene/Solr QA commented on SOLR-12881:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 62 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 10m 
52s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 10m  
9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 10m  
9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  2m 32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m 18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m 18s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  8m 
25s{color} | {color:green} common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  0m 
19s{color} | {color:green} icu in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  1m 
30s{color} | {color:green} kuromoji in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  1m 
15s{color} | {color:green} phonetic in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  0m 
36s{color} | {color:green} stempel in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  1m 
22s{color} | {color:green} backward-codecs in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  8m 
44s{color} | {color:green} codecs in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 31m  
9s{color} | {color:green} core in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  0m 
17s{color} | {color:green} expressions in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  1m 
25s{color} | {color:green} facet in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m  
2s{color} | {color:green} misc in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m  
8s{color} | {color:green} spatial3d in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  3m  
3s{color} | {color:green} suggest in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  4m 
45s{color} | {color:green} test-framework in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  0m 15s{color} 
| {color:red} tools in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m 
33s{color} | {color:green} analytics in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  3m 
27s{color} | {color:green} dataimporthandler in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  1m  
9s{color} | {color:green} ltr in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 84m  6s{color} 
| {color:red} core in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  7m 17s{color} 
| {color:red} solrj in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}194m 59s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.schema.TestManagedSchemaAPI |
|   | solr.handler.TestSolrConfigHandlerConcurrent |
|   | solr.client.solrj.io.stream.MathExpressionTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12881 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12944415/SOLR-12881.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 

[JENKINS] Lucene-Solr-repro - Build # 1718 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/1718/

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1670/consoleText

[repro] Revision: 11a1b8c1a8fdca9f6314bd61695345737309b630

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=HdfsRestartWhileUpdatingTest 
-Dtests.method=test -Dtests.seed=D916C0D081241E28 -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=ar-EG -Dtests.timezone=America/Argentina/Rio_Gallegos 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=LIROnShardRestartTest 
-Dtests.method=testSeveralReplicasInLIR -Dtests.seed=D916C0D081241E28 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=ar-KW -Dtests.timezone=SystemV/CST6CDT -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=LIROnShardRestartTest 
-Dtests.method=testAllReplicasInLIR -Dtests.seed=D916C0D081241E28 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=ar-KW -Dtests.timezone=SystemV/CST6CDT -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=RestartWhileUpdatingTest 
-Dtests.method=test -Dtests.seed=D916C0D081241E28 -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=th -Dtests.timezone=NST -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=RestartWhileUpdatingTest 
-Dtests.seed=D916C0D081241E28 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=th -Dtests.timezone=NST -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
167c65afadc164beb870337a1076ef146387b55d
[repro] git fetch
[repro] git checkout 11a1b8c1a8fdca9f6314bd61695345737309b630

[...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]   RestartWhileUpdatingTest
[repro]   HdfsRestartWhileUpdatingTest
[repro]   LIROnShardRestartTest
[repro] ant compile-test

[...truncated 3424 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=15 
-Dtests.class="*.RestartWhileUpdatingTest|*.HdfsRestartWhileUpdatingTest|*.LIROnShardRestartTest"
 -Dtests.showOutput=onerror -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.seed=D916C0D081241E28 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt
 -Dtests.locale=th -Dtests.timezone=NST -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[...truncated 306139 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.cloud.hdfs.HdfsRestartWhileUpdatingTest
[repro]   2/5 failed: org.apache.solr.cloud.LIROnShardRestartTest
[repro]   3/5 failed: org.apache.solr.cloud.RestartWhileUpdatingTest
[repro] git checkout 167c65afadc164beb870337a1076ef146387b55d

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 6 lines...]

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr issue #451: LUCENE-8496: Add selective indexing to BKD/POINTS co...

[nknize]

Github user nknize commented on the issue:

https://github.com/apache/lucene-solr/pull/451
  
closing with commit 1118299c338253cea09640acdc48dc930dc27fda


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr pull request #451: LUCENE-8496: Add selective indexing to BKD/PO...

[nknize]

Github user nknize closed the pull request at:

https://github.com/apache/lucene-solr/pull/451


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-8496) Explore selective dimension indexing in BKDReader/Writer

[Nicholas Knize (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicholas Knize updated LUCENE-8496:
---
Affects Version/s: master (8.0)
   7.6

> Explore selective dimension indexing in BKDReader/Writer
> 
>
> Key: LUCENE-8496
> URL: https://issues.apache.org/jira/browse/LUCENE-8496
> Project: Lucene - Core
>  Issue Type: New Feature
>Affects Versions: 7.6, master (8.0)
>Reporter: Nicholas Knize
>Priority: Major
> Attachments: LUCENE-8496.patch, LUCENE-8496.patch, LUCENE-8496.patch, 
> LUCENE-8496.patch, LUCENE-8496.patch, LatLonShape_SelectiveEncoding.patch
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> This issue explores adding a new feature to BKDReader/Writer that enables 
> users to select a fewer number of dimensions to be used for creating the BKD 
> index than the total number of dimensions specified for field encoding. This 
> is useful for encoding dimensional data that is used for interpreting the 
> encoded field data but unnecessary (or not efficient) for creating the index 
> structure. One such example is {{LatLonShape}} encoding. The first 4 
> dimensions may be used to to efficiently search/index the triangle using its 
> precomputed bounding box as a 4D point, and the remaining dimensions can be 
> used to encode the vertices of the tessellated triangle. This causes BKD to 
> act much like an R-Tree for shape data where search is distilled into a 4D 
> point (instead of a more expensive 6D point) and the triangle is encoded 
> using a portion of the remaining (non-indexed) dimensions. Fields that use 
> the full data range for indexing are not impacted and behave as they normally 
> would.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8496) Explore selective dimension indexing in BKDReader/Writer

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1667#comment-1667
 ] 

ASF subversion and git services commented on LUCENE-8496:
-

Commit 804afbfd47cc8d86ceda6ea66f0afe304af1ad1b in lucene-solr's branch 
refs/heads/branch_7x from [~nknize]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=804afbf ]

LUCENE-8496: Selective indexing - modify BKDReader/BKDWriter to allow users to 
select a fewer number of dimensions to be used for creating the index than the 
total number of dimensions used for field encoding. i.e., dimensions 0 to N may 
be used to determine how to split the inner nodes, and dimensions N+1 to D are 
ignored and stored as data dimensions at the leaves.


> Explore selective dimension indexing in BKDReader/Writer
> 
>
> Key: LUCENE-8496
> URL: https://issues.apache.org/jira/browse/LUCENE-8496
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
>Priority: Major
> Attachments: LUCENE-8496.patch, LUCENE-8496.patch, LUCENE-8496.patch, 
> LUCENE-8496.patch, LUCENE-8496.patch, LatLonShape_SelectiveEncoding.patch
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> This issue explores adding a new feature to BKDReader/Writer that enables 
> users to select a fewer number of dimensions to be used for creating the BKD 
> index than the total number of dimensions specified for field encoding. This 
> is useful for encoding dimensional data that is used for interpreting the 
> encoded field data but unnecessary (or not efficient) for creating the index 
> structure. One such example is {{LatLonShape}} encoding. The first 4 
> dimensions may be used to to efficiently search/index the triangle using its 
> precomputed bounding box as a 4D point, and the remaining dimensions can be 
> used to encode the vertices of the tessellated triangle. This causes BKD to 
> act much like an R-Tree for shape data where search is distilled into a 4D 
> point (instead of a more expensive 6D point) and the triangle is encoded 
> using a portion of the remaining (non-indexed) dimensions. Fields that use 
> the full data range for indexing are not impacted and behave as they normally 
> would.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8374) Reduce reads for sparse DocValues

[Tim Underwood (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655457#comment-16655457
 ] 

Tim Underwood commented on LUCENE-8374:
---

I just tested this out and am seeing a really good Solr faceting performance 
increase!  One of the facet heavy queries that I've been using for testing on 
SOLR-12878 and SOLR-12882 went from ~88 queries per second to ~190 queries per 
second!

 

*Index Stats:*

Total Docs: 83,846,867 (~1 million parent docs and the rest are child documents)

Index Size (on disk): 30.53 GB

 

*Query Stats:*

The query I'm using performs JSON facets against the child documents on 41 
IntPoint fields that makes up one of the queries used to generate this page:  
[https://www.opticatonline.com/search?bv=18220=usa] . The facets are 
shown on the left side of the page.  The "Part Type" (single valued) and 
"Assembly Group" (multi-valued) are populated for every document.  The "Linkage 
Criteria" make up the rest of the 41 fields and are sparsely populated with 
data (if at all).

I can share more details if interested.

 

When I get a chance I'll test this on my other large index that has less 
overall documents (8 million total) but they are all densely populated with 
multi-valued string fields that are used for faceting.

> Reduce reads for sparse DocValues
> -
>
> Key: LUCENE-8374
> URL: https://issues.apache.org/jira/browse/LUCENE-8374
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/codecs
>Affects Versions: 7.4, master (8.0)
>Reporter: Toke Eskildsen
>Priority: Major
>  Labels: performance
> Fix For: master (8.0)
>
> Attachments: LUCENE-8374.patch, LUCENE-8374.patch, LUCENE-8374.patch, 
> LUCENE-8374.patch, LUCENE-8374.patch, LUCENE-8374_branch_7_3.patch, 
> LUCENE-8374_branch_7_4.patch
>
>
> The {{Lucene70DocValuesProducer}} has the internal classes 
> {{SparseNumericDocValues}} and {{BaseSortedSetDocValues}} (sparse code path), 
> which again uses {{IndexedDISI}} to handle the docID -> value-ordinal lookup. 
> The value-ordinal is the index of the docID assuming an abstract tightly 
> packed monotonically increasing list of docIDs: If the docIDs with 
> corresponding values are {{[0, 4, 1432]}}, their value-ordinals will be {{[0, 
> 1, 2]}}.
> h2. Outer blocks
> The lookup structure of {{IndexedDISI}} consists of blocks of 2^16 values 
> (65536), where each block can be either {{ALL}}, {{DENSE}} (2^12 to 2^16 
> values) or {{SPARSE}} (< 2^12 values ~= 6%). Consequently blocks vary quite a 
> lot in size and ordinal resolving strategy.
> When a sparse Numeric DocValue is needed, the code first locates the block 
> containing the wanted docID flag. It does so by iterating blocks one-by-one 
> until it reaches the needed one, where each iteration requires a lookup in 
> the underlying {{IndexSlice}}. For a common memory mapped index, this 
> translates to either a cached request or a read operation. If a segment has 
> 6M documents, worst-case is 91 lookups. In our web archive, our segments has 
> ~300M values: A worst-case of 4577 lookups!
> One obvious solution is to use a lookup-table for blocks: A long[]-array with 
> an entry for each block. For 6M documents, that is < 1KB and would allow for 
> direct jumping (a single lookup) in all instances. Unfortunately this 
> lookup-table cannot be generated upfront when the writing of values is purely 
> streaming. It can be appended to the end of the stream before it is closed, 
> but without knowing the position of the lookup-table the reader cannot seek 
> to it.
> One strategy for creating such a lookup-table would be to generate it during 
> reads and cache it for next lookup. This does not fit directly into how 
> {{IndexedDISI}} currently works (it is created anew for each invocation), but 
> could probably be added with a little work. An advantage to this is that this 
> does not change the underlying format and thus could be used with existing 
> indexes.
> h2. The lookup structure inside each block
> If {{ALL}} of the 2^16 values are defined, the structure is empty and the 
> ordinal is simply the requested docID with some modulo and multiply math. 
> Nothing to improve there.
> If the block is {{DENSE}} (2^12 to 2^16 values are defined), a bitmap is used 
> and the number of set bits up to the wanted index (the docID modulo the block 
> origo) are counted. That bitmap is a long[1024], meaning that worst case is 
> to lookup and count all set bits for 1024 longs!
> One known solution to this is to use a [rank 
> structure|[https://en.wikipedia.org/wiki/Succinct_data_structure]]. I 
> [implemented 
> it|[https://github.com/tokee/lucene-solr/blob/solr5894/solr/core/src/java/org/apache/solr/search/sparse/count/plane/RankCache.java]]
>  for a related 

Re: Academic question about Solr's embedded web server

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Erick,

On 10/14/18 00:03, Erick Erickson wrote:
> Can we stick to the question? Which is "what advantages Tomcat
> might bring to be worth the _very_ significant effort it would take
> to replace Jetty, assuming that it's a choice between the two".

I just read that someone is building an alpha SPNEGO implementation
for Solr. Tomcat ships with one. That might be one item in its favor.

Given that most servlet containers are nominally equivalent, I'm not
sure I could build a compelling case for why you *should* switch to
Tomcat. But given that there is an opportunity to re-evaluate the
container you will use (e.g. if you switch from container-hosted Solr
to Solr-hosted container), then switching becomes easier should you
choose to switch.

The decision to move to Tomcat may be made simply to prefer a product
with a clean AL2 license (Jetty has restrictions; I haven't read them
but I suspect they are not really problematic in any meaningful way).

> For the level of effort required to make the switch to Tomcat, I
> suspect the consensus would be to use neither and switch to Netty
> or similar, which makes the discussion so far pretty much a waste
> of electrons.

So, if you think switching to Netty will be worth it, I'd like to know
*those* reasons. Netty is a great product, but you only benefit if you
abandon the servlet spec and build to their non-standard APIs. That
would basically require a ground-up rebuild of Solr from scratch in
order to gain any perceivable benefit from switching to Netty.

If you guys would like to see some independent performance
evaluations, have a look at this:

https://www.javacodegeeks.com/2016/05/benchmarking-high-concurrency-http
- -servers-jvm.html

Skip to the graphs. They are nearly impossible to read, but show that
all servers benchmarked seem to have roughly the same performance
characteristics. Basically, you can't go wrong. Anything that might
seriously impact your performance will come down to resources
(hardware) or configuration (e.g. if you want fast TLS, don't use the
Java crypto provider).

I know there are some throughput-vs-CPU-usage numbers around for
Tomcat versus httpd and one of two other servers/configurations. I'm
trying to dig those up.

Thanks,
- -chris

> Erick On Sat, Oct 13, 2018 at 6:24 PM Christopher Schultz 
>  wrote:
>> 
> Martin,
> 
> Wow, wild conjecture with no supporting evidence. Seems like par
> for the course with you. Read on, if you dare.
> 
> On 10/13/18 13:41, Martin Gainty wrote:
 
 ---
- ---
>>
>>
 
- -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
>> additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 
> -
>
> 
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvInIUACgkQHPApP6U8
pFh0JQ/+J53IZkbqdKnWLa4ndg8v2AZrhrWha0YHSMlOih9k7ANcw+0G0jtTek6m
l2CTgQOuKGGn3/PVfP6OypEXOhQ2XR/VQBrUCZzKzLIlEcEEiyLV0vb9fm4HnmIR
KwEsgU0pnTIwsE540F8eP/MK5AqQ2ULqMlsX+m19U0/RAx6PnXQGGxAORRIVLFi/
mK7Yu1Ou2pbT/3W1iL63fbbkmDgyeRqo6lthWvwa2Q+zAq/qe/N4drJ1dAYdSg4c
L6xY5JVVYFRlS2+2Cc0TeBNB3yVsRPakz4Q4P+GKyTOS61yuXsPL/DhDpLdHqca9
WkRrG0MBVPM9X7HRd7PrNvzJIyeEJYFLOEt7UFrZ/tmMlmZD5M5w33L4na2ZJN86
MKxcCQz3M/FySfbaKmrRBu8BAIkCmmU7DAMdGUCLJKQ3sdHknc7QisLARrY0Xx17
nDjXcKxu0lrO6ZTKJ1/nHwGZz1tEe+cgJKwcEyTWlFnYm1IS0A9FlMHdePvA54Jh
x1J4cW7qut5ir1WS3Un7K52RndGGXNVTfkyTsJnCx9+65Wuq86M+lgEuyiRCuhVL
wUpCx2l3qNcTCOZjUj+i8cq1aJIEm+Ql7EeS9JEB4Y+2yCOhgPS9lKotTTLmVFbK
2ccG9nyMu8iPN2UPyT+VqN+9HmXZ/FVQj2lTfU02lAlWZODxu88=
=tcIz
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10465) setIdField should be deprecated in favor of SolrClientBuilder methods

[Charles Sanders (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655222#comment-16655222
 ] 

Charles Sanders commented on SOLR-10465:


Updated the patch.  Changed idField to routingField as suggested in the 
previous comment.

> setIdField should be deprecated in favor of SolrClientBuilder methods
> -
>
> Key: SOLR-10465
> URL: https://issues.apache.org/jira/browse/SOLR-10465
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: 7.0
>
> Attachments: SOLR-10465.patch, SOLR-10465.patch
>
>
> Now that builders are in place for {{SolrClients}}, the setters used in each 
> {{SolrClient}} can be deprecated, and their functionality moved over to the 
> Builders. This change brings a few benefits:
> - unifies {{SolrClient}} configuration under the new Builders. It'll be nice 
> to have all the knobs, and levers used to tweak {{SolrClient}}s available in 
> a single place (the Builders).
> - reduces {{SolrClient}} thread-safety concerns. Currently, clients are 
> mutable. Using some {{SolrClient}} setters can result in erratic and "trappy" 
> behavior when the clients are used across multiple threads.
> This subtask endeavors to change this behavior for the {{setIdField}} setter 
> on all {{SolrClient}} implementations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-10465) setIdField should be deprecated in favor of SolrClientBuilder methods

[Charles Sanders (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Charles Sanders updated SOLR-10465:
---
Attachment: SOLR-10465.patch

> setIdField should be deprecated in favor of SolrClientBuilder methods
> -
>
> Key: SOLR-10465
> URL: https://issues.apache.org/jira/browse/SOLR-10465
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: 7.0
>
> Attachments: SOLR-10465.patch, SOLR-10465.patch
>
>
> Now that builders are in place for {{SolrClients}}, the setters used in each 
> {{SolrClient}} can be deprecated, and their functionality moved over to the 
> Builders. This change brings a few benefits:
> - unifies {{SolrClient}} configuration under the new Builders. It'll be nice 
> to have all the knobs, and levers used to tweak {{SolrClient}}s available in 
> a single place (the Builders).
> - reduces {{SolrClient}} thread-safety concerns. Currently, clients are 
> mutable. Using some {{SolrClient}} setters can result in erratic and "trappy" 
> behavior when the clients are used across multiple threads.
> This subtask endeavors to change this behavior for the {{setIdField}} setter 
> on all {{SolrClient}} implementations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-12-ea+12) - Build # 23050 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23050/
Java: 64bit/jdk-12-ea+12 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

49 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.DocValuesNotIndexedTest

Error Message:
Collection not found: dv_coll

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: dv_coll
at __randomizedtesting.SeedInfo.seed([A4DA337C6268020A]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:851)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.createCluster(DocValuesNotIndexedTest.java:154)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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:835)


FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.DocValuesNotIndexedTest

Error Message:
Collection not found: dv_coll

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: dv_coll
at __randomizedtesting.SeedInfo.seed([A4DA337C6268020A]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:851)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.createCluster(DocValuesNotIndexedTest.java:154)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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 

[jira] [Updated] (SOLR-12799) Allow Authentication Plugins to easily intercept internode requests

[Noble Paul (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul updated SOLR-12799:
--
Attachment: SOLR-12799.patch

> Allow Authentication Plugins to easily intercept internode requests
> ---
>
> Key: SOLR-12799
> URL: https://issues.apache.org/jira/browse/SOLR-12799
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: SOLR-12799.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Solr security framework currently allows a plugin to declare statically by 
> implementing the {{HttpClientBuilderPlugin}} interface whether it will handle 
> internode requests. If it implements the interface, the plugin MUST handle 
> ALL internode requests, even requests originating from Solr itself. Likewise, 
> if a plugin does not implement the interface, ALL requests will be 
> authenticated by the built-in {{PKIAuthenticationPlugin}}.
> In some cases (such as SOLR-12121) there is a need to forward end-user 
> credentials on internode requests, but let PKI handle it for solr-originated 
> requests. This is currently not possible without a dirty hack where each 
> plugin duplicates some PKI logic and calls PKI plugin from its own 
> interceptor even if it is disabled.
> This Jira makes this use case officially supported by the framework by:
>  * Letting {{PKIAuthenticationPlugin}} be always enabled. PKI will now in its 
> interceptor on a per-request basis first give the authc plugin a chance to 
> handle the request
>  * Adding a protected method to abstract class {{AuthenticationPlugin}}
>{code:java}
> protected boolean interceptInternodeRequest(HttpRequest httpRequest, 
> HttpContext httpContext)
> {code}
> that can be overridden by plugins in order to easily intercept requests 
> without registering its own interceptor. Returning 'false' delegates to PKI.
> Existing Authc plugins do *not* need to change as a result of this, and they 
> will work exactly as before, i.e. either handle ALL or NONE internode auth.
> New plugins choosing to *override* the new {{interceptInternodeRequest}} 
> method will obtain per-request control over who will secure each request. The 
> first user of this feature will be JWT token based auth in SOLR-12121.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12799) Allow Authentication Plugins to easily intercept internode requests

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655200#comment-16655200
 ] 

Noble Paul commented on SOLR-12799:
---

I have attached a patch which includes the changes

> Allow Authentication Plugins to easily intercept internode requests
> ---
>
> Key: SOLR-12799
> URL: https://issues.apache.org/jira/browse/SOLR-12799
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: SOLR-12799.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Solr security framework currently allows a plugin to declare statically by 
> implementing the {{HttpClientBuilderPlugin}} interface whether it will handle 
> internode requests. If it implements the interface, the plugin MUST handle 
> ALL internode requests, even requests originating from Solr itself. Likewise, 
> if a plugin does not implement the interface, ALL requests will be 
> authenticated by the built-in {{PKIAuthenticationPlugin}}.
> In some cases (such as SOLR-12121) there is a need to forward end-user 
> credentials on internode requests, but let PKI handle it for solr-originated 
> requests. This is currently not possible without a dirty hack where each 
> plugin duplicates some PKI logic and calls PKI plugin from its own 
> interceptor even if it is disabled.
> This Jira makes this use case officially supported by the framework by:
>  * Letting {{PKIAuthenticationPlugin}} be always enabled. PKI will now in its 
> interceptor on a per-request basis first give the authc plugin a chance to 
> handle the request
>  * Adding a protected method to abstract class {{AuthenticationPlugin}}
>{code:java}
> protected boolean interceptInternodeRequest(HttpRequest httpRequest, 
> HttpContext httpContext)
> {code}
> that can be overridden by plugins in order to easily intercept requests 
> without registering its own interceptor. Returning 'false' delegates to PKI.
> Existing Authc plugins do *not* need to change as a result of this, and they 
> will work exactly as before, i.e. either handle ALL or NONE internode auth.
> New plugins choosing to *override* the new {{interceptInternodeRequest}} 
> method will obtain per-request control over who will secure each request. The 
> first user of this feature will be JWT token based auth in SOLR-12121.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7075) Clean up LegacyNumericUtils usage.

[Simon Willnauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655195#comment-16655195
 ] 

Simon Willnauer commented on LUCENE-7075:
-

+1 to resolve

> Clean up LegacyNumericUtils usage.
> --
>
> Key: LUCENE-7075
> URL: https://issues.apache.org/jira/browse/LUCENE-7075
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Robert Muir
>Priority: Blocker
>
> Tons of code is still on the deprecated LegacyNumericUtils. We will never be 
> able to remove these or even move them to somewhere better (like the 
> backwards jar) if we don't clean this up!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr pull request #480: LUCENE-8535: Drop out of the box Block-Join h...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/lucene-solr/pull/480


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-8535) Should we drop support for highlighting block-join queries

[Simon Willnauer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Willnauer resolved LUCENE-8535.
-
   Resolution: Fixed
Fix Version/s: master (8.0)

> Should we drop support for highlighting block-join queries
> --
>
> Key: LUCENE-8535
> URL: https://issues.apache.org/jira/browse/LUCENE-8535
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: master (8.0)
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> This is a spin-off from LUCENE-6572. We currently depend on the block-join 
> module which is due to the fact that we try to highlight the queries wrapped 
> by the block join queries. The current discussion on LUCENE-6572 mentioned 
> that this doesn't make much sense from an highlighting perspecitve and if we 
> should drop support for it. Lucene 8.0 would be a good time to do so.
> Thoughts?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8535) Should we drop support for highlighting block-join queries

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655192#comment-16655192
 ] 

ASF subversion and git services commented on LUCENE-8535:
-

Commit 5a4fd86cce57586dd14fb8f11f9b170b121eebc4 in lucene-solr's branch 
refs/heads/master from [~simonw]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5a4fd86 ]

LUCENE-8535: Drop out of the box Block-Join highlight support

Highlighter doesn't support ToParent and ToChildBlockJoinQuery out of the
box anymore. In oder to highlight on Block-Join Queries a custom 
WeightedSpanTermExtractor
should be used.


> Should we drop support for highlighting block-join queries
> --
>
> Key: LUCENE-8535
> URL: https://issues.apache.org/jira/browse/LUCENE-8535
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> This is a spin-off from LUCENE-6572. We currently depend on the block-join 
> module which is due to the fact that we try to highlight the queries wrapped 
> by the block join queries. The current discussion on LUCENE-6572 mentioned 
> that this doesn't make much sense from an highlighting perspecitve and if we 
> should drop support for it. Lucene 8.0 would be a good time to do so.
> Thoughts?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12881) Remove unneeded import statements

[Peter Somogyi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655143#comment-16655143
 ] 

Peter Somogyi commented on SOLR-12881:
--

Most of the imports that I removed were from the same package, so technically 
they are not unused import but not required. There were a couple of occurrences 
where wildcard imports were used and additionally a class was imported from the 
same package. There were only a few import which were 
[unused|https://github.com/apache/lucene-solr/pull/475/commits/3584ef30f1c3c5cddc19fcd510731ac0846654c0#diff-11a7bf85508185a5104561dffb3da648].

 

> Remove unneeded import statements
> -
>
> Key: SOLR-12881
> URL: https://issues.apache.org/jira/browse/SOLR-12881
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (8.0)
>Reporter: Peter Somogyi
>Priority: Trivial
> Attachments: SOLR-12881.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There are unnecessary import statements:
>  * import from java.lang
>  * import from same package
>  * unused import



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12881) Remove unneeded import statements

[JIRA]

[ 
https://issues.apache.org/jira/browse/SOLR-12881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655060#comment-16655060
 ] 

Jan Høydahl commented on SOLR-12881:


Hmm, there should be no unused imports in master, since the build disallows 
that by rule by precommit? And won't the IDEs add back those other imports 
automatically?

> Remove unneeded import statements
> -
>
> Key: SOLR-12881
> URL: https://issues.apache.org/jira/browse/SOLR-12881
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (8.0)
>Reporter: Peter Somogyi
>Priority: Trivial
> Attachments: SOLR-12881.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There are unnecessary import statements:
>  * import from java.lang
>  * import from same package
>  * unused import



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 184 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/184/

2 tests failed.
FAILED:  org.apache.solr.cloud.MoveReplicaTest.test

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([8BB1AED47ED1CBD7:3E5910ED02DA62F]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at org.junit.Assert.assertFalse(Assert.java:79)
at org.apache.solr.cloud.MoveReplicaTest.test(MoveReplicaTest.java:148)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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)


FAILED:  
org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest.testInactiveShardCleanup

Error Message:
missing cleanup event: [CapturedEvent{timestamp=990941629069757, stage=STARTED, 
actionName='null', event={   "id":"385419379d73cTa78l05n8pwoa45cwfrf15sysq",   
"source":".scheduled_maintenance",   

[jira] [Resolved] (LUCENE-8533) DataInput#readVInt() supports negative numbers although not documented

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler resolved LUCENE-8533.
---
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.6

> DataInput#readVInt() supports negative numbers although not documented
> --
>
> Key: LUCENE-8533
> URL: https://issues.apache.org/jira/browse/LUCENE-8533
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Vladimir Dolzhenko
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 7.6, master (8.0)
>
> Attachments: LUCENE-8533_fix_readVInt_javadoc.patch, readVInt.patch
>
>
> {{readVInt()}} has to return positive numbers (and zero), throw some 
> exception in case of negative numbers.
> While for the sequence of bytes {{[-1, -1, -1, -1, 15]}} it returns {{-1}}.
> simplifying 
> [readVInt|https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/lucene/core/src/java/org/apache/lucene/store/DataInput.java#L113]
>  up to last readByte (exclusive):
> {code:java}
> int i = ((byte)-1) & 0x7F;
> i |= (((byte)-1) & 0x7F) << 7;
> i |= (((byte)-1) & 0x7F) << 14;
> i |= (((byte)-1) & 0x7F) << 21;
> {code}
> Here {{i = 268435455}} or in binary format is 
> {{___}}
> Keeping in mind that {{int}} is a signed type we have only 3 more bits before 
> overflow happens or in another words {{(Integer.MAX_VALUE - i) >> 28 == 7}} - 
> that's max value could be stored in 5th byte to avoid overflow.
> Instead of 
> {code:java}
> i |= (b & 0x0F) << 28;
> if ((b & 0xF0) == 0) return i;
> {code}
> has to be
> {code:java}
> i |= (b & 0x07) << 28;
> if ((b & 0xF8) == 0) return i;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8533) DataInput#readVInt() supports negative numbers although not documented

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655031#comment-16655031
 ] 

Uwe Schindler commented on LUCENE-8533:
---

OK, I committed this change. IMHO, changing this is a larger task (it's not 
only the -1 you mentioned). So I am closing this issue. If we want to change 
this, we should open a new issue and plan the change.

> DataInput#readVInt() supports negative numbers although not documented
> --
>
> Key: LUCENE-8533
> URL: https://issues.apache.org/jira/browse/LUCENE-8533
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Vladimir Dolzhenko
>Assignee: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-8533_fix_readVInt_javadoc.patch, readVInt.patch
>
>
> {{readVInt()}} has to return positive numbers (and zero), throw some 
> exception in case of negative numbers.
> While for the sequence of bytes {{[-1, -1, -1, -1, 15]}} it returns {{-1}}.
> simplifying 
> [readVInt|https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/lucene/core/src/java/org/apache/lucene/store/DataInput.java#L113]
>  up to last readByte (exclusive):
> {code:java}
> int i = ((byte)-1) & 0x7F;
> i |= (((byte)-1) & 0x7F) << 7;
> i |= (((byte)-1) & 0x7F) << 14;
> i |= (((byte)-1) & 0x7F) << 21;
> {code}
> Here {{i = 268435455}} or in binary format is 
> {{___}}
> Keeping in mind that {{int}} is a signed type we have only 3 more bits before 
> overflow happens or in another words {{(Integer.MAX_VALUE - i) >> 28 == 7}} - 
> that's max value could be stored in 5th byte to avoid overflow.
> Instead of 
> {code:java}
> i |= (b & 0x0F) << 28;
> if ((b & 0xF0) == 0) return i;
> {code}
> has to be
> {code:java}
> i |= (b & 0x07) << 28;
> if ((b & 0xF8) == 0) return i;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-8533) DataInput#readVInt() supports negative numbers although not documented

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-8533:
--
Summary: DataInput#readVInt() supports negative numbers although not 
documented  (was: Incorrect readVInt: negative number could be returned)

> DataInput#readVInt() supports negative numbers although not documented
> --
>
> Key: LUCENE-8533
> URL: https://issues.apache.org/jira/browse/LUCENE-8533
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Vladimir Dolzhenko
>Assignee: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-8533_fix_readVInt_javadoc.patch, readVInt.patch
>
>
> {{readVInt()}} has to return positive numbers (and zero), throw some 
> exception in case of negative numbers.
> While for the sequence of bytes {{[-1, -1, -1, -1, 15]}} it returns {{-1}}.
> simplifying 
> [readVInt|https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/lucene/core/src/java/org/apache/lucene/store/DataInput.java#L113]
>  up to last readByte (exclusive):
> {code:java}
> int i = ((byte)-1) & 0x7F;
> i |= (((byte)-1) & 0x7F) << 7;
> i |= (((byte)-1) & 0x7F) << 14;
> i |= (((byte)-1) & 0x7F) << 21;
> {code}
> Here {{i = 268435455}} or in binary format is 
> {{___}}
> Keeping in mind that {{int}} is a signed type we have only 3 more bits before 
> overflow happens or in another words {{(Integer.MAX_VALUE - i) >> 28 == 7}} - 
> that's max value could be stored in 5th byte to avoid overflow.
> Instead of 
> {code:java}
> i |= (b & 0x0F) << 28;
> if ((b & 0xF0) == 0) return i;
> {code}
> has to be
> {code:java}
> i |= (b & 0x07) << 28;
> if ((b & 0xF8) == 0) return i;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-9.0.4) - Build # 2934 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2934/
Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica

Error Message:
Expected new active leader null Live Nodes: [127.0.0.1:36155_solr, 
127.0.0.1:36901_solr, 127.0.0.1:40605_solr] Last available state: 
DocCollection(raceDeleteReplica_false//collections/raceDeleteReplica_false/state.json/11)={
   "pullReplicas":"0",   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node3":{   "core":"raceDeleteReplica_false_shard1_replica_n1",
   "base_url":"https://127.0.0.1:44149/solr;,   
"node_name":"127.0.0.1:44149_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false",   "leader":"true"},  
   "core_node6":{   
"core":"raceDeleteReplica_false_shard1_replica_n5",   
"base_url":"https://127.0.0.1:44149/solr;,   
"node_name":"127.0.0.1:44149_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"1",   
"autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: Expected new active leader
null
Live Nodes: [127.0.0.1:36155_solr, 127.0.0.1:36901_solr, 127.0.0.1:40605_solr]
Last available state: 
DocCollection(raceDeleteReplica_false//collections/raceDeleteReplica_false/state.json/11)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node3":{
  "core":"raceDeleteReplica_false_shard1_replica_n1",
  "base_url":"https://127.0.0.1:44149/solr;,
  "node_name":"127.0.0.1:44149_solr",
  "state":"down",
  "type":"NRT",
  "force_set_state":"false",
  "leader":"true"},
"core_node6":{
  "core":"raceDeleteReplica_false_shard1_replica_n5",
  "base_url":"https://127.0.0.1:44149/solr;,
  "node_name":"127.0.0.1:44149_solr",
  "state":"down",
  "type":"NRT",
  "force_set_state":"false",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([D19E650891FFBE77:BB8804D8F90DF4BD]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:280)
at 
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:334)
at 
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:230)
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:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at 

[jira] [Commented] (LUCENE-8533) Incorrect readVInt: negative number could be returned

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655030#comment-16655030
 ] 

ASF subversion and git services commented on LUCENE-8533:
-

Commit 22d91a0acc78559d80cbaab69bb7ec5042ec8fb7 in lucene-solr's branch 
refs/heads/branch_7x from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=22d91a0 ]

LUCENE-8533: Fix Javadocs of DataInput#readVInt(): Negative numbers are 
supported, but should be avoided.


> Incorrect readVInt: negative number could be returned
> -
>
> Key: LUCENE-8533
> URL: https://issues.apache.org/jira/browse/LUCENE-8533
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Vladimir Dolzhenko
>Assignee: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-8533_fix_readVInt_javadoc.patch, readVInt.patch
>
>
> {{readVInt()}} has to return positive numbers (and zero), throw some 
> exception in case of negative numbers.
> While for the sequence of bytes {{[-1, -1, -1, -1, 15]}} it returns {{-1}}.
> simplifying 
> [readVInt|https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/lucene/core/src/java/org/apache/lucene/store/DataInput.java#L113]
>  up to last readByte (exclusive):
> {code:java}
> int i = ((byte)-1) & 0x7F;
> i |= (((byte)-1) & 0x7F) << 7;
> i |= (((byte)-1) & 0x7F) << 14;
> i |= (((byte)-1) & 0x7F) << 21;
> {code}
> Here {{i = 268435455}} or in binary format is 
> {{___}}
> Keeping in mind that {{int}} is a signed type we have only 3 more bits before 
> overflow happens or in another words {{(Integer.MAX_VALUE - i) >> 28 == 7}} - 
> that's max value could be stored in 5th byte to avoid overflow.
> Instead of 
> {code:java}
> i |= (b & 0x0F) << 28;
> if ((b & 0xF0) == 0) return i;
> {code}
> has to be
> {code:java}
> i |= (b & 0x07) << 28;
> if ((b & 0xF8) == 0) return i;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8533) Incorrect readVInt: negative number could be returned

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655029#comment-16655029
 ] 

ASF subversion and git services commented on LUCENE-8533:
-

Commit 167c65afadc164beb870337a1076ef146387b55d in lucene-solr's branch 
refs/heads/master from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=167c65a ]

LUCENE-8533: Fix Javadocs of DataInput#readVInt(): Negative numbers are 
supported, but should be avoided.


> Incorrect readVInt: negative number could be returned
> -
>
> Key: LUCENE-8533
> URL: https://issues.apache.org/jira/browse/LUCENE-8533
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Vladimir Dolzhenko
>Assignee: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-8533_fix_readVInt_javadoc.patch, readVInt.patch
>
>
> {{readVInt()}} has to return positive numbers (and zero), throw some 
> exception in case of negative numbers.
> While for the sequence of bytes {{[-1, -1, -1, -1, 15]}} it returns {{-1}}.
> simplifying 
> [readVInt|https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/lucene/core/src/java/org/apache/lucene/store/DataInput.java#L113]
>  up to last readByte (exclusive):
> {code:java}
> int i = ((byte)-1) & 0x7F;
> i |= (((byte)-1) & 0x7F) << 7;
> i |= (((byte)-1) & 0x7F) << 14;
> i |= (((byte)-1) & 0x7F) << 21;
> {code}
> Here {{i = 268435455}} or in binary format is 
> {{___}}
> Keeping in mind that {{int}} is a signed type we have only 3 more bits before 
> overflow happens or in another words {{(Integer.MAX_VALUE - i) >> 28 == 7}} - 
> that's max value could be stored in 5th byte to avoid overflow.
> Instead of 
> {code:java}
> i |= (b & 0x0F) << 28;
> if ((b & 0xF0) == 0) return i;
> {code}
> has to be
> {code:java}
> i |= (b & 0x07) << 28;
> if ((b & 0xF8) == 0) return i;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Lucene/Solr 8.0

[Đạt Cao Mạnh]

Thanks Cassandra and Jim,

I created a blocker issue for Solr 8.0 SOLR-12883
, currently in jira/http2
branch there are a draft-unmature implementation of SPNEGO authentication
which enough to makes the test pass, this implementation will be removed
when SOLR-12883 gets resolved . Therefore I don't see any problem on
merging jira/http2 to master branch in the next week.

On Thu, Oct 18, 2018 at 2:33 AM jim ferenczi  wrote:

> > But if you're working with a different assumption - that just the
> existence of the branch does not stop Dat from still merging his work and
> the work being included in 8.0 - then I agree, waiting for him to merge
> doesn't need to stop the creation of the branch.
>
> Yes that's my reasoning. This issue is a blocker so we won't release
> without it but we can work on the branch in the meantime and let other
> people work on new features that are not targeted to 8.
>
> Le mer. 17 oct. 2018 à 20:51, Cassandra Targett  a
> écrit :
>
>> OK - I was making an assumption that the timeline for the first 8.0 RC
>> would be ASAP after the branch is created.
>>
>> It's a common perception that making a branch freezes adding new features
>> to the release, perhaps in an unofficial way (more of a courtesy rather
>> than a rule). But if you're working with a different assumption - that just
>> the existence of the branch does not stop Dat from still merging his work
>> and the work being included in 8.0 - then I agree, waiting for him to merge
>> doesn't need to stop the creation of the branch.
>>
>> If, however, once the branch is there people object to Dat merging his
>> work because it's "too late", then the branch shouldn't be created yet
>> because we want to really try to clear that blocker for 8.0.
>>
>> Cassandra
>>
>> On Wed, Oct 17, 2018 at 12:13 PM jim ferenczi 
>> wrote:
>>
>>> Ok thanks for answering.
>>>
>>> > - I think Solr needs a couple more weeks since the work Dat is doing
>>> isn't quite done yet.
>>>
>>> We can wait a few more weeks to create the branch but I don't think that
>>> one action (creating the branch) prevents the other (the work Dat is doing).
>>> HTTP/2 is one of the blocker for the release but it can be done in
>>> master and backported to the appropriate branch as any other feature ? We
>>> just need an issue with the blocker label to ensure that
>>> we don't miss it ;). Creating the branch early would also help in case
>>> you don't want to release all the work at once in 8.0.0.
>>> Next week was just a proposal, what I meant was soon because we target a
>>> release in a few months.
>>>
>>>
>>> Le mer. 17 oct. 2018 à 17:52, Cassandra Targett 
>>> a écrit :
>>>
 IMO next week is a bit too soon for the branch - I think Solr needs a
 couple more weeks since the work Dat is doing isn't quite done yet.

 Solr needs the HTTP/2 work Dat has been doing, and he told me yesterday
 he feels it is nearly ready to be merged into master. However, it does
 require a new release of Jetty to Solr is able to retain Kerberos
 authentication support (Dat has been working with that team to help test
 the changes Jetty needs to support Kerberos with HTTP/2). They should get
 that release out soon, but we are dependent on them a little bit.

 He can hopefully reply with more details on his status and what else
 needs to be done.

 Once Dat merges his work, IMO we should leave it in master for a little
 bit. While he has been beasting and testing with Jenkins as he goes along,
 I think it would be good to have all the regular master builds work on it
 for a little bit also.

 Of the other blockers, the only other large-ish one is to fully remove
 Trie* fields, which some of us also discussed yesterday and it seemed we
 concluded that Solr isn't really ready to do that. The performance issues
 with single value lookups are a major obstacle. It would be nice if someone
 with a bit more experience with that could comment in the issue
 (SOLR-12632) and/or unmark it as a blocker.

 Cassandra

 On Wed, Oct 17, 2018 at 8:38 AM Erick Erickson 
 wrote:

> I find 9 open blockers for 8.0:
>
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20priority%20%3D%20Blocker%20AND%20status%20%3D%20OPEN
>
> As David mentioned, many of the SOlr committers are at Activate, which
> ends Thursday so feedback (and work) may be a bit delayed.
> On Wed, Oct 17, 2018 at 8:11 AM David Smiley 
> wrote:
> >
> > Hi,
> >
> > Thanks for volunteering to do the 8.0 release Jim!
> >
> > Many of us are at the Activate Conference in Montreal.  We had a
> committers meeting where we discussed some of the blockers.  I think only 
> a
> couple items were raised.  I'll leave Dat to discuss the one on HTTP2.  On
> the Solr nested docs front, I articulated one 

[jira] [Created] (SOLR-12883) Upgrade to Jetty 9.4.13

[Cao Manh Dat (JIRA)]

Cao Manh Dat created SOLR-12883:
---

 Summary: Upgrade to Jetty 9.4.13
 Key: SOLR-12883
 URL: https://issues.apache.org/jira/browse/SOLR-12883
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Cao Manh Dat
Assignee: Cao Manh Dat


Start from 9.4.13 Jetty Client started to support SPNEGO authentication, 
therefore this is the crucial missed part for jira/http2 branch which switched 
internal communication from Apache HttpClient to Jetty Client.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8533) Incorrect readVInt: negative number could be returned

[Vladimir Dolzhenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654982#comment-16654982
 ] 

Vladimir Dolzhenko commented on LUCENE-8533:


Patch [^LUCENE-8533_fix_readVInt_javadoc.patch] to fix javadoc is attached.

> Incorrect readVInt: negative number could be returned
> -
>
> Key: LUCENE-8533
> URL: https://issues.apache.org/jira/browse/LUCENE-8533
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Vladimir Dolzhenko
>Assignee: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-8533_fix_readVInt_javadoc.patch, readVInt.patch
>
>
> {{readVInt()}} has to return positive numbers (and zero), throw some 
> exception in case of negative numbers.
> While for the sequence of bytes {{[-1, -1, -1, -1, 15]}} it returns {{-1}}.
> simplifying 
> [readVInt|https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/lucene/core/src/java/org/apache/lucene/store/DataInput.java#L113]
>  up to last readByte (exclusive):
> {code:java}
> int i = ((byte)-1) & 0x7F;
> i |= (((byte)-1) & 0x7F) << 7;
> i |= (((byte)-1) & 0x7F) << 14;
> i |= (((byte)-1) & 0x7F) << 21;
> {code}
> Here {{i = 268435455}} or in binary format is 
> {{___}}
> Keeping in mind that {{int}} is a signed type we have only 3 more bits before 
> overflow happens or in another words {{(Integer.MAX_VALUE - i) >> 28 == 7}} - 
> that's max value could be stored in 5th byte to avoid overflow.
> Instead of 
> {code:java}
> i |= (b & 0x0F) << 28;
> if ((b & 0xF0) == 0) return i;
> {code}
> has to be
> {code:java}
> i |= (b & 0x07) << 28;
> if ((b & 0xF8) == 0) return i;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-8533) Incorrect readVInt: negative number could be returned

[Vladimir Dolzhenko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Dolzhenko updated LUCENE-8533:
---
Attachment: LUCENE-8533_fix_readVInt_javadoc.patch

> Incorrect readVInt: negative number could be returned
> -
>
> Key: LUCENE-8533
> URL: https://issues.apache.org/jira/browse/LUCENE-8533
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Vladimir Dolzhenko
>Assignee: Uwe Schindler
>Priority: Major
> Attachments: LUCENE-8533_fix_readVInt_javadoc.patch, readVInt.patch
>
>
> {{readVInt()}} has to return positive numbers (and zero), throw some 
> exception in case of negative numbers.
> While for the sequence of bytes {{[-1, -1, -1, -1, 15]}} it returns {{-1}}.
> simplifying 
> [readVInt|https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/lucene/core/src/java/org/apache/lucene/store/DataInput.java#L113]
>  up to last readByte (exclusive):
> {code:java}
> int i = ((byte)-1) & 0x7F;
> i |= (((byte)-1) & 0x7F) << 7;
> i |= (((byte)-1) & 0x7F) << 14;
> i |= (((byte)-1) & 0x7F) << 21;
> {code}
> Here {{i = 268435455}} or in binary format is 
> {{___}}
> Keeping in mind that {{int}} is a signed type we have only 3 more bits before 
> overflow happens or in another words {{(Integer.MAX_VALUE - i) >> 28 == 7}} - 
> that's max value could be stored in 5th byte to avoid overflow.
> Instead of 
> {code:java}
> i |= (b & 0x0F) << 28;
> if ((b & 0xF0) == 0) return i;
> {code}
> has to be
> {code:java}
> i |= (b & 0x07) << 28;
> if ((b & 0xF8) == 0) return i;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr issue #480: LUCENE-8535: Drop out of the box Block-Join highligh...

[uschindler]

Github user uschindler commented on the issue:

https://github.com/apache/lucene-solr/pull/480
  
Thanks for removing the dependency hell!


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr issue #480: LUCENE-8535: Drop out of the box Block-Join highligh...

[s1monw]

Github user s1monw commented on the issue:

https://github.com/apache/lucene-solr/pull/480
  
@jimczi pushed some changes


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8533) Incorrect readVInt: negative number could be returned

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654913#comment-16654913
 ] 

Uwe Schindler commented on LUCENE-8533:
---

I think we should at least fix the documentation in javadocs to be in sync with 
writeVInt. Can you provide a patch?

Uwe

> Incorrect readVInt: negative number could be returned
> -
>
> Key: LUCENE-8533
> URL: https://issues.apache.org/jira/browse/LUCENE-8533
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Vladimir Dolzhenko
>Assignee: Uwe Schindler
>Priority: Major
> Attachments: readVInt.patch
>
>
> {{readVInt()}} has to return positive numbers (and zero), throw some 
> exception in case of negative numbers.
> While for the sequence of bytes {{[-1, -1, -1, -1, 15]}} it returns {{-1}}.
> simplifying 
> [readVInt|https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/lucene/core/src/java/org/apache/lucene/store/DataInput.java#L113]
>  up to last readByte (exclusive):
> {code:java}
> int i = ((byte)-1) & 0x7F;
> i |= (((byte)-1) & 0x7F) << 7;
> i |= (((byte)-1) & 0x7F) << 14;
> i |= (((byte)-1) & 0x7F) << 21;
> {code}
> Here {{i = 268435455}} or in binary format is 
> {{___}}
> Keeping in mind that {{int}} is a signed type we have only 3 more bits before 
> overflow happens or in another words {{(Integer.MAX_VALUE - i) >> 28 == 7}} - 
> that's max value could be stored in 5th byte to avoid overflow.
> Instead of 
> {code:java}
> i |= (b & 0x0F) << 28;
> if ((b & 0xF0) == 0) return i;
> {code}
> has to be
> {code:java}
> i |= (b & 0x07) << 28;
> if ((b & 0xF8) == 0) return i;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-12-ea+12) - Build # 23049 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23049/
Java: 64bit/jdk-12-ea+12 -XX:-UseCompressedOops -XX:+UseG1GC

63 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.io.stream.StreamDecoratorTest

Error Message:
20 threads leaked from SUITE scope at 
org.apache.solr.client.solrj.io.stream.StreamDecoratorTest: 1) 
Thread[id=447, 
name=TEST-StreamDecoratorTest.testExecutorStream-seed#[D6C7E8ED95614006]-EventThread,
 state=WAITING, group=TGRP-StreamDecoratorTest] at 
java.base@12-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@12-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@12-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
 at 
java.base@12-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
 at 
app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)2) 
Thread[id=448, name=zkConnectionManagerCallback-195-thread-1, state=WAITING, 
group=TGRP-StreamDecoratorTest] at 
java.base@12-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@12-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@12-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
 at 
java.base@12-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
 at 
java.base@12-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054)
 at 
java.base@12-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
 at 
java.base@12-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
 at java.base@12-ea/java.lang.Thread.run(Thread.java:835)3) 
Thread[id=2045, 
name=TEST-StreamDecoratorTest.testParallelExecutorStream-seed#[D6C7E8ED95614006]-SendThread(127.0.0.1:35893),
 state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at 
java.base@12-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.zookeeper.ClientCnxnSocketNIO.cleanup(ClientCnxnSocketNIO.java:230)
 at 
app//org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1249)   
  at 
app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1173)4) 
Thread[id=2051, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-StreamDecoratorTest] at 
java.base@12-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@12-ea/java.lang.Thread.run(Thread.java:835)5) 
Thread[id=459, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-StreamDecoratorTest] at 
java.base@12-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@12-ea/java.lang.Thread.run(Thread.java:835)6) 
Thread[id=3266, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-StreamDecoratorTest] at 
java.base@12-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@12-ea/java.lang.Thread.run(Thread.java:835)7) 
Thread[id=3269, name=zkConnectionManagerCallback-1609-thread-1, state=WAITING, 
group=TGRP-StreamDecoratorTest] at 
java.base@12-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@12-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@12-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
 at 
java.base@12-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
 at 
java.base@12-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054)
 at 
java.base@12-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
 at 
java.base@12-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
 at java.base@12-ea/java.lang.Thread.run(Thread.java:835)8) 
Thread[id=3272, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-StreamDecoratorTest] at 
java.base@12-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@12-ea/java.lang.Thread.run(Thread.java:835)9) 
Thread[id=458, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-StreamDecoratorTest] at 
java.base@12-ea/java.lang.Thread.sleep(Native Method) at 

[jira] [Commented] (LUCENE-8533) Incorrect readVInt: negative number could be returned

[Vladimir Dolzhenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654909#comment-16654909
 ] 

Vladimir Dolzhenko commented on LUCENE-8533:


Thank Uwe for the details and comments.

There is at least one place where {{writeVInt(-1)}} is used explicitly :

[DirectDocValuesConsumer:149|https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/lucene/codecs/src/java/org/apache/lucene/codecs/memory/DirectDocValuesConsumer.java#L149]

it has to be addressed before dropping negative support for {{vInt}}

> Incorrect readVInt: negative number could be returned
> -
>
> Key: LUCENE-8533
> URL: https://issues.apache.org/jira/browse/LUCENE-8533
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Vladimir Dolzhenko
>Assignee: Uwe Schindler
>Priority: Major
> Attachments: readVInt.patch
>
>
> {{readVInt()}} has to return positive numbers (and zero), throw some 
> exception in case of negative numbers.
> While for the sequence of bytes {{[-1, -1, -1, -1, 15]}} it returns {{-1}}.
> simplifying 
> [readVInt|https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/lucene/core/src/java/org/apache/lucene/store/DataInput.java#L113]
>  up to last readByte (exclusive):
> {code:java}
> int i = ((byte)-1) & 0x7F;
> i |= (((byte)-1) & 0x7F) << 7;
> i |= (((byte)-1) & 0x7F) << 14;
> i |= (((byte)-1) & 0x7F) << 21;
> {code}
> Here {{i = 268435455}} or in binary format is 
> {{___}}
> Keeping in mind that {{int}} is a signed type we have only 3 more bits before 
> overflow happens or in another words {{(Integer.MAX_VALUE - i) >> 28 == 7}} - 
> that's max value could be stored in 5th byte to avoid overflow.
> Instead of 
> {code:java}
> i |= (b & 0x0F) << 28;
> if ((b & 0xF0) == 0) return i;
> {code}
> has to be
> {code:java}
> i |= (b & 0x07) << 28;
> if ((b & 0xF8) == 0) return i;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8531) QueryBuilder hard-codes inOrder=true for generated sloppy span near queries

[Jim Ferenczi (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654901#comment-16654901
 ] 

Jim Ferenczi commented on LUCENE-8531:
--

> It would be interesting how Elasticsearch handles this in its matchPhrase 
> queries.

The match query in Elasticsearch uses a QueryBuilder under the hood so we have 
the same bug. 

> IMHO, no need for extra param, as this is/was a bug.

agreed, we should adapt the query depending on the slop value to ensure 
consistency
 

> QueryBuilder hard-codes inOrder=true for generated sloppy span near queries
> ---
>
> Key: LUCENE-8531
> URL: https://issues.apache.org/jira/browse/LUCENE-8531
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: LUCENE-8531.patch
>
>
> QueryBuilder.analyzeGraphPhrase() generates SpanNearQuery-s with passed-in 
> phraseSlop, but hard-codes inOrder ctor param as true.
> Before multi-term synonym support and graph token streams introduced the 
> possibility of generating SpanNearQuery-s, QueryBuilder generated 
> (Multi)PhraseQuery-s, which always interpret slop as allowing reordering 
> edits.  Solr's eDismax query parser generates phrase queries when its 
> pf/pf2/pf3 params are specified, and when multi-term synonyms are used with a 
> graph-aware synonym filter, SpanNearQuery-s are generated that require 
> clauses to be in order; unlike with (Multi)PhraseQuery-s, reordering edits 
> are not allowed, so this is a kind of regression.  See SOLR-12243 for edismax 
> pf/pf2/pf3 context.  (Note that the patch on SOLR-12243 also addresses 
> another problem that blocks eDismax from generating queries *at all* under 
> the above-described circumstances.)
> I propose adding a new analyzeGraphPhrase() method that allows configuration 
> of inOrder, which would allow eDismax to specify inOrder=false.  The existing 
> analyzeGraphPhrase() method would remain with its hard-coded inOrder=true, so 
> existing client behavior would remain unchanged.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8531) QueryBuilder hard-codes inOrder=true for generated sloppy span near queries

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654896#comment-16654896
 ] 

Uwe Schindler commented on LUCENE-8531:
---

IMHO, no need for extra param, as this is/was a bug.

> QueryBuilder hard-codes inOrder=true for generated sloppy span near queries
> ---
>
> Key: LUCENE-8531
> URL: https://issues.apache.org/jira/browse/LUCENE-8531
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: LUCENE-8531.patch
>
>
> QueryBuilder.analyzeGraphPhrase() generates SpanNearQuery-s with passed-in 
> phraseSlop, but hard-codes inOrder ctor param as true.
> Before multi-term synonym support and graph token streams introduced the 
> possibility of generating SpanNearQuery-s, QueryBuilder generated 
> (Multi)PhraseQuery-s, which always interpret slop as allowing reordering 
> edits.  Solr's eDismax query parser generates phrase queries when its 
> pf/pf2/pf3 params are specified, and when multi-term synonyms are used with a 
> graph-aware synonym filter, SpanNearQuery-s are generated that require 
> clauses to be in order; unlike with (Multi)PhraseQuery-s, reordering edits 
> are not allowed, so this is a kind of regression.  See SOLR-12243 for edismax 
> pf/pf2/pf3 context.  (Note that the patch on SOLR-12243 also addresses 
> another problem that blocks eDismax from generating queries *at all* under 
> the above-described circumstances.)
> I propose adding a new analyzeGraphPhrase() method that allows configuration 
> of inOrder, which would allow eDismax to specify inOrder=false.  The existing 
> analyzeGraphPhrase() method would remain with its hard-coded inOrder=true, so 
> existing client behavior would remain unchanged.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8531) QueryBuilder hard-codes inOrder=true for generated sloppy span near queries

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654895#comment-16654895
 ] 

Uwe Schindler commented on LUCENE-8531:
---

Thanks Jim for the idea.

I was following the previous issue on the Solr side and I agree that the 
behaviour needs to be consistent. But as Jim says, there is no need for some 
additional "inOrder" parameter as Steve suggested. The analyzePhrase stuff 
should always behave identical to a pure phrase query, so the inOrder behaviour 
needs to be consistent with a pure phrase query. If slop is > 0 then in order 
should be false, no optional parameter needed.

This would also fix Solr's bug and Lucene would be consistent. Jim's workaround 
to prevent using SpanQuery if slop is > 1 is perfectly fine, although might be 
a bit slower. It would be interesting how Elasticsearch handles this in its 
matchPhrase queries.

> QueryBuilder hard-codes inOrder=true for generated sloppy span near queries
> ---
>
> Key: LUCENE-8531
> URL: https://issues.apache.org/jira/browse/LUCENE-8531
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: LUCENE-8531.patch
>
>
> QueryBuilder.analyzeGraphPhrase() generates SpanNearQuery-s with passed-in 
> phraseSlop, but hard-codes inOrder ctor param as true.
> Before multi-term synonym support and graph token streams introduced the 
> possibility of generating SpanNearQuery-s, QueryBuilder generated 
> (Multi)PhraseQuery-s, which always interpret slop as allowing reordering 
> edits.  Solr's eDismax query parser generates phrase queries when its 
> pf/pf2/pf3 params are specified, and when multi-term synonyms are used with a 
> graph-aware synonym filter, SpanNearQuery-s are generated that require 
> clauses to be in order; unlike with (Multi)PhraseQuery-s, reordering edits 
> are not allowed, so this is a kind of regression.  See SOLR-12243 for edismax 
> pf/pf2/pf3 context.  (Note that the patch on SOLR-12243 also addresses 
> another problem that blocks eDismax from generating queries *at all* under 
> the above-described circumstances.)
> I propose adding a new analyzeGraphPhrase() method that allows configuration 
> of inOrder, which would allow eDismax to specify inOrder=false.  The existing 
> analyzeGraphPhrase() method would remain with its hard-coded inOrder=true, so 
> existing client behavior would remain unchanged.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12243) Edismax missing phrase queries when phrases contain multiterm synonyms

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654888#comment-16654888
 ] 

Uwe Schindler commented on SOLR-12243:
--

I am fine with splitting those issues!

> Edismax missing phrase queries when phrases contain multiterm synonyms
> --
>
> Key: SOLR-12243
> URL: https://issues.apache.org/jira/browse/SOLR-12243
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 7.1
> Environment: RHEL, MacOS X
> Do not believe this is environment-specific.
>Reporter: Elizabeth Haubert
>Assignee: Uwe Schindler
>Priority: Major
> Attachments: SOLR-12243.patch, SOLR-12243.patch, SOLR-12243.patch, 
> SOLR-12243.patch, SOLR-12243.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> synonyms.txt:
> {code}
> allergic, hypersensitive
> aspirin, acetylsalicylic acid
> dog, canine, canis familiris, k 9
> rat, rattus
> {code}
> request handler:
> {code:xml}
> 
>  
> 
>  edismax
>   0.4
>  title^100
>  title~20^5000
>  title~11
>  title~22^1000
>  text
>  
>  3-1 6-3 930%
>  *:*
>  25
> 
> 
> {code}
> Phrase queries (pf, pf2, pf3) containing "dog" or "aspirin"  against the 
> above list will not be generated.
> "allergic reaction dog" will generate pf2: "allergic reaction", but not 
> pf:"allergic reaction dog", pf2: "reaction dog", or pf3: "allergic reaction 
> dog"
> "aspirin dose in rats" will generate pf3: "dose ? rats" but not pf2: "aspirin 
> dose" or pf3:"aspirin dose ?"
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

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

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/1715/

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-BadApples-NightlyTests-7.x/31/consoleText

[repro] Revision: 7a2504e18c1508ed5b44ef5692d216b19f9d6a6b

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=SearchRateTriggerIntegrationTest 
-Dtests.method=testBelowSearchRate -Dtests.seed=ED0D86404D2DC638 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=el-GR -Dtests.timezone=Europe/Kiev -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=SearchRateTriggerIntegrationTest 
-Dtests.method=testDeleteNode -Dtests.seed=ED0D86404D2DC638 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=el-GR -Dtests.timezone=Europe/Kiev -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestSimLargeCluster 
-Dtests.method=testNodeLost -Dtests.seed=ED0D86404D2DC638 -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=en -Dtests.timezone=America/Whitehorse -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=CollectionsAPISolrJTest 
-Dtests.method=testCollectionProp -Dtests.seed=ED0D86404D2DC638 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=sr-Latn-BA -Dtests.timezone=Asia/Baghdad -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=CollectionsAPISolrJTest 
-Dtests.method=testAddAndDeleteReplica -Dtests.seed=ED0D86404D2DC638 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=sr-Latn-BA -Dtests.timezone=Asia/Baghdad -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=CollectionsAPISolrJTest 
-Dtests.method=testSplitShard -Dtests.seed=ED0D86404D2DC638 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=sr-Latn-BA -Dtests.timezone=Asia/Baghdad -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=CollectionsAPISolrJTest 
-Dtests.method=testCreateWithDefaultConfigSet -Dtests.seed=ED0D86404D2DC638 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=sr-Latn-BA -Dtests.timezone=Asia/Baghdad -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestSimComputePlanAction 
-Dtests.method=testNodeWithMultipleReplicasLost -Dtests.seed=ED0D86404D2DC638 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=it-IT -Dtests.timezone=America/Dawson -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestSimTriggerIntegration 
-Dtests.method=testSearchRate -Dtests.seed=ED0D86404D2DC638 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=sv -Dtests.timezone=Africa/Khartoum -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestSimTriggerIntegration 
-Dtests.method=testNodeAddedTriggerRestoreState -Dtests.seed=ED0D86404D2DC638 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=sv 

[jira] [Updated] (LUCENE-8536) The bytes parameter of the copy method is not carefully checked.

[Hao Zhong (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hao Zhong updated LUCENE-8536:
--
Summary: The bytes parameter of the copy method is not carefully checked.  
(was: The bytes parameter of the copy can be overflowed.)

> The bytes parameter of the copy method is not carefully checked.
> 
>
> Key: LUCENE-8536
> URL: https://issues.apache.org/jira/browse/LUCENE-8536
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: -tools
>Affects Versions: trunk
>Reporter: Hao Zhong
>Priority: Major
>
> The copy method of the PagedBytes class is as follow:
>  
>  
> {code:java}
> public void copy(BytesRef bytes, BytesRef out) {
> int left = blockSize - upto;
> if (bytes.length > left || currentBlock==null) {
> if (currentBlock != null) {
> addBlock(currentBlock);
> didSkipBytes = true;
> }
> currentBlock = new byte[blockSize];
> upto = 0;
> left = blockSize;
> assert bytes.length <= blockSize;
> // TODO: we could also support variable block sizes
> }
> out.bytes = currentBlock;
> out.offset = upto;
> out.length = bytes.length;
> System.arraycopy(bytes.bytes, bytes.offset, currentBlock, upto, bytes.length);
> upto += bytes.length;
> }
> {code}
> The method does not throw exceptions for illegal inputs. In the same class, 
> the copyUsingLengthPrefix method checks the input value"
>  
>  
>  
> {code:java}
> public long copyUsingLengthPrefix(BytesRef bytes) {
> if (bytes.length >= 32768) {
> throw new IllegalArgumentException("max length is 32767 (got " + bytes.length 
> + ")");
> }
> if (upto + bytes.length + 2 > blockSize) {
> if (bytes.length + 2 > blockSize) {
> throw new IllegalArgumentException("block size " + blockSize + " is too small 
> to store length " + bytes.length + " bytes");
> }
> if (currentBlock != null) {
> addBlock(currentBlock); 
> }
> currentBlock = new byte[blockSize];
> upto = 0;
> }
> final long pointer = getPointer();
> if (bytes.length < 128) {
> currentBlock[upto++] = (byte) bytes.length;
> } else {
> currentBlock[upto++] = (byte) (0x80 | (bytes.length >> 8));
> currentBlock[upto++] = (byte) (bytes.length & 0xff);
> }
> System.arraycopy(bytes.bytes, bytes.offset, currentBlock, upto, bytes.length);
> upto += bytes.length;
> return pointer;
> }
> {code}
> I understand that in the first method, 
> {code:java}
> assert bytes.length <= blockSize;{code}
> checks whether the length of the bytes is too large. However,  the method 
> does not check blockSize either. As a result, the length of the bytes can 
> still be overflowed, if blockSize is too large.  In addition, the second 
> method also checks whether 
> {code:java}
> bytes.length + 2 > blockSize{code}
> Shall the first method also checks the requirement?
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-8536) The bytes parameter of the copy can be overflowed.

[Hao Zhong (JIRA)]

Hao Zhong created LUCENE-8536:
-

 Summary: The bytes parameter of the copy can be overflowed.
 Key: LUCENE-8536
 URL: https://issues.apache.org/jira/browse/LUCENE-8536
 Project: Lucene - Core
  Issue Type: Bug
  Components: -tools
Affects Versions: trunk
Reporter: Hao Zhong


The copy method of the PagedBytes class is as follow:

 

 
{code:java}
public void copy(BytesRef bytes, BytesRef out) {
int left = blockSize - upto;
if (bytes.length > left || currentBlock==null) {
if (currentBlock != null) {
addBlock(currentBlock);
didSkipBytes = true;
}
currentBlock = new byte[blockSize];
upto = 0;
left = blockSize;
assert bytes.length <= blockSize;
// TODO: we could also support variable block sizes
}

out.bytes = currentBlock;
out.offset = upto;
out.length = bytes.length;

System.arraycopy(bytes.bytes, bytes.offset, currentBlock, upto, bytes.length);
upto += bytes.length;
}
{code}
The method does not throw exceptions for illegal inputs. In the same class, the 
copyUsingLengthPrefix method checks the input value"

 

 

 
{code:java}
public long copyUsingLengthPrefix(BytesRef bytes) {
if (bytes.length >= 32768) {
throw new IllegalArgumentException("max length is 32767 (got " + bytes.length + 
")");
}

if (upto + bytes.length + 2 > blockSize) {
if (bytes.length + 2 > blockSize) {
throw new IllegalArgumentException("block size " + blockSize + " is too small 
to store length " + bytes.length + " bytes");
}
if (currentBlock != null) {
addBlock(currentBlock); 
}
currentBlock = new byte[blockSize];
upto = 0;
}

final long pointer = getPointer();

if (bytes.length < 128) {
currentBlock[upto++] = (byte) bytes.length;
} else {
currentBlock[upto++] = (byte) (0x80 | (bytes.length >> 8));
currentBlock[upto++] = (byte) (bytes.length & 0xff);
}
System.arraycopy(bytes.bytes, bytes.offset, currentBlock, upto, bytes.length);
upto += bytes.length;

return pointer;
}
{code}
I understand that in the first method, 
{code:java}
assert bytes.length <= blockSize;{code}
checks whether the length of the bytes is too large. However,  the method does 
not check blockSize either. As a result, the length of the bytes can still be 
overflowed, if blockSize is too large.  In addition, the second method also 
checks whether 
{code:java}
bytes.length + 2 > blockSize{code}
Shall the first method also checks the requirement?

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8507) TopFieldCollector should set minimum competitive score if the primary sort is by relevancy

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654870#comment-16654870
 ] 

Alan Woodward commented on LUCENE-8507:
---

+1

> TopFieldCollector should set minimum competitive score if the primary sort is 
> by relevancy
> --
>
> Key: LUCENE-8507
> URL: https://issues.apache.org/jira/browse/LUCENE-8507
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Jim Ferenczi
>Priority: Minor
> Attachments: LUCENE-8507.patch, LUCENE-8507.patch
>
>
> When the primary sort in the TopFieldCollector is set to relevancy it is 
> possible to update the minimum competitive score like the TopScoreCollector 
> does. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr pull request #480: LUCENE-8535: Drop out of the box Block-Join h...

[jimczi]

Github user jimczi commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/480#discussion_r226211884
  
--- Diff: lucene/CHANGES.txt ---
@@ -123,6 +123,10 @@ Changes in Runtime Behavior
 * LUCENE-8505: IndexWriter#addIndices will now fail if the target index is 
sorted but
   the candidate is not. (Jim Ferenczi)
 
+* LUCENE-8535: Highlighter doesn't support ToParent and 
ToChildBlockJoinQuery out of the
+  box anymore. In oder to highlight on Block-Join Queries a custom 
WeightedSpanTermExtractor
--- End diff --

nit: s/oder/order/


---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-8535) Should we drop support for highlighting block-join queries

[Dawid Weiss (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dawid Weiss updated LUCENE-8535:

Summary: Should we drop support for highlighting block-join queries  (was: 
Should we drop support for highlighting block-join queris)

> Should we drop support for highlighting block-join queries
> --
>
> Key: LUCENE-8535
> URL: https://issues.apache.org/jira/browse/LUCENE-8535
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This is a spin-off from LUCENE-6572. We currently depend on the block-join 
> module which is due to the fact that we try to highlight the queries wrapped 
> by the block join queries. The current discussion on LUCENE-6572 mentioned 
> that this doesn't make much sense from an highlighting perspecitve and if we 
> should drop support for it. Lucene 8.0 would be a good time to do so.
> Thoughts?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8535) Should we drop support for highlighting block-join queris

[Simon Willnauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16654847#comment-16654847
 ] 

Simon Willnauer commented on LUCENE-8535:
-

[~jim.ferenczi] I referenced a github PR for this, can you take a look?

> Should we drop support for highlighting block-join queris
> -
>
> Key: LUCENE-8535
> URL: https://issues.apache.org/jira/browse/LUCENE-8535
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This is a spin-off from LUCENE-6572. We currently depend on the block-join 
> module which is due to the fact that we try to highlight the queries wrapped 
> by the block join queries. The current discussion on LUCENE-6572 mentioned 
> that this doesn't make much sense from an highlighting perspecitve and if we 
> should drop support for it. Lucene 8.0 would be a good time to do so.
> Thoughts?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr pull request #480: LUCENE-8535: Drop out of the box Block-Join h...

[s1monw]

GitHub user s1monw opened a pull request:

https://github.com/apache/lucene-solr/pull/480

LUCENE-8535: Drop out of the box Block-Join highlight support

Highlighter doesn't support ToParent and ToChildBlockJoinQuery out of the
box anymore. In oder to highlight on Block-Join Queries a custom 
WeightedSpanTermExtractor
should be used.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/s1monw/lucene-solr LUCENE-8535

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/480.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #480


commit 6d775d5613700bb01a9d7eb8f44ae9a9acb8b2d2
Author: Simon Willnauer 
Date:   2018-10-18T08:15:57Z

LUCENE-8535: Drop out of the box Block-Join highlight support

Highlighter doesn't support ToParent and ToChildBlockJoinQuery out of the
box anymore. In oder to highlight on Block-Join Queries a custom 
WeightedSpanTermExtractor
should be used.




---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-8480) Completion regex query uses UTF32 automaton

[Jim Ferenczi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jim Ferenczi updated LUCENE-8480:
-
  Priority: Minor  (was: Major)
Issue Type: Bug  (was: Test)

> Completion regex query uses UTF32 automaton
> ---
>
> Key: LUCENE-8480
> URL: https://issues.apache.org/jira/browse/LUCENE-8480
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Jim Ferenczi
>Priority: Minor
>
> The completion regex query builds an UTF-32 automaton but the completion FST 
> uses UTF-8 internally. This makes the matching of any non basic latin 
> character impossible in a regex completion query. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-8507) TopFieldCollector should set minimum competitive score if the primary sort is by relevancy

[Jim Ferenczi (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620552#comment-16620552
 ] 

Jim Ferenczi edited comment on LUCENE-8507 at 10/18/18 8:09 AM:


Here is a new patch that tweaks the logics a bit in order to reduce the 
additional conditions we need to check to set the minimum score. I ran a 
benchmark with luceneutil on queries sorted by field to compare with current 
master:
{noformat}
Report after iter 19:
TaskQPS lucene_baseline  StdDevQPS lucene_candidate 
 StdDevPct diff
   HighTermMonthSort   38.06  (9.6%)   37.53  (9.9%)   
-1.4% ( -19% -   19%)
   HighTermDayOfYearSort   16.22  (7.0%)   16.47  (6.0%)
1.5% ( -10% -   15%)
{noformat}


was (Author: jim.ferenczi):
Here is a new patch that tweaks the logics a bit in order to reduce the 
additional conditions we need to check to set the minimum score. I ran a 
benchmark with luceneutil on queries sorted by field to compare with current 
master:
{noformat}
Report after iter 19:
TaskQPS lucene_baseline  StdDevQPS lucene_candidate 
 StdDevPct diff
   HighTermMonthSort   38.06  (9.6%)   37.53  (9.9%)   
-1.4% ( -19% -   19%)
   HighTermDayOfYearSort   16.22  (7.0%)   16.47  (6.0%)
1.5% ( -10% -   15%)
{noformat}

> TopFieldCollector should set minimum competitive score if the primary sort is 
> by relevancy
> --
>
> Key: LUCENE-8507
> URL: https://issues.apache.org/jira/browse/LUCENE-8507
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Jim Ferenczi
>Priority: Minor
> Attachments: LUCENE-8507.patch, LUCENE-8507.patch
>
>
> When the primary sort in the TopFieldCollector is set to relevancy it is 
> possible to update the minimum competitive score like the TopScoreCollector 
> does. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-BadApples-7.x-Linux (64bit/jdk-11) - Build # 107 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-7.x-Linux/107/
Java: 64bit/jdk-11 -XX:+UseCompressedOops -XX:+UseParallelGC

67 tests failed.
FAILED:  org.apache.solr.client.solrj.io.sql.JdbcTest.testConnectionParams

Error Message:
java.sql.SQLException: java.io.IOException: --> 
https://127.0.0.1:38771/solr/collection1_shard2_replica_n2/:Failed to execute 
sqlQuery 'select a_s, sum(a_f) from collection1 group by a_s order by sum(a_f) 
desc' against JDBC connection 'jdbc:calcitesolr:'. Error while executing SQL 
"select a_s, sum(a_f) from collection1 group by a_s order by sum(a_f) desc": 
java.io.IOException: java.util.concurrent.ExecutionException: 
java.io.IOException: --> 
https://127.0.0.1:43741/solr/collection1_shard1_replica_n1/:java.util.concurrent.ExecutionException:
 java.io.IOException: params 
fl=a_s,a_f=*:*=javabin=/export=a_s=a_s+desc=false

Stack Trace:
java.sql.SQLException: java.sql.SQLException: java.io.IOException: --> 
https://127.0.0.1:38771/solr/collection1_shard2_replica_n2/:Failed to execute 
sqlQuery 'select a_s, sum(a_f) from collection1 group by a_s order by sum(a_f) 
desc' against JDBC connection 'jdbc:calcitesolr:'.
Error while executing SQL "select a_s, sum(a_f) from collection1 group by a_s 
order by sum(a_f) desc": java.io.IOException: 
java.util.concurrent.ExecutionException: java.io.IOException: --> 
https://127.0.0.1:43741/solr/collection1_shard1_replica_n1/:java.util.concurrent.ExecutionException:
 java.io.IOException: params 
fl=a_s,a_f=*:*=javabin=/export=a_s=a_s+desc=false
at 
__randomizedtesting.SeedInfo.seed([73983442AAF3220E:5BA95683E3C34265]:0)
at 
org.apache.solr.client.solrj.io.sql.StatementImpl.executeQueryImpl(StatementImpl.java:74)
at 
org.apache.solr.client.solrj.io.sql.StatementImpl.executeQuery(StatementImpl.java:111)
at 
org.apache.solr.client.solrj.io.sql.JdbcTest.testConnectionParams(JdbcTest.java:290)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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