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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.6-Linux/37/
Java: 64bit/jdk1.8.0_172 -XX:+UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest.testSimple

Error Message:
Waiting for collection testSimple2 null Live Nodes: [127.0.0.1:42623_solr, 
127.0.0.1:44845_solr] Last available state: 
DocCollection(testSimple2//collections/testSimple2/state.json/20)={   
"pullReplicas":"0",   "replicationFactor":"2",   "shards":{ "shard1":{  
 "range":"8000-",   "state":"active",   "replicas":{
 "core_node3":{   
"dataDir":"hdfs://localhost.localdomain:33665/data/testSimple2/core_node3/data/",
   "base_url":"https://127.0.0.1:35599/solr";,   
"node_name":"127.0.0.1:35599_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost.localdomain:33665/data/testSimple2/core_node3/data/tlog",
   "core":"testSimple2_shard1_replica_n1",   
"shared_storage":"true",   "state":"down"}, "core_node5":{  
 
"dataDir":"hdfs://localhost.localdomain:33665/data/testSimple2/core_node5/data/",
   "base_url":"https://127.0.0.1:42623/solr";,   
"node_name":"127.0.0.1:42623_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost.localdomain:33665/data/testSimple2/core_node5/data/tlog",
   "core":"testSimple2_shard1_replica_n2",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}}}, "shard2":{   "range":"0-7fff",   
"state":"active",   "replicas":{ "core_node7":{   
"dataDir":"hdfs://localhost.localdomain:33665/data/testSimple2/core_node7/data/",
   "base_url":"https://127.0.0.1:35599/solr";,   
"node_name":"127.0.0.1:35599_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost.localdomain:33665/data/testSimple2/core_node7/data/tlog",
   "core":"testSimple2_shard2_replica_n4",   
"shared_storage":"true",   "state":"down"}, "core_node8":{  
 
"dataDir":"hdfs://localhost.localdomain:33665/data/testSimple2/core_node8/data/",
   "base_url":"https://127.0.0.1:42623/solr";,   
"node_name":"127.0.0.1:42623_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost.localdomain:33665/data/testSimple2/core_node8/data/tlog",
   "core":"testSimple2_shard2_replica_n6",   
"shared_storage":"true",   "state":"active",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"2",   "autoAddReplicas":"true",   "nrtReplicas":"2",   
"tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: Waiting for collection testSimple2
null
Live Nodes: [127.0.0.1:42623_solr, 127.0.0.1:44845_solr]
Last available state: 
DocCollection(testSimple2//collections/testSimple2/state.json/20)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{
"shard1":{
  "range":"8000-",
  "state":"active",
  "replicas":{
"core_node3":{
  
"dataDir":"hdfs://localhost.localdomain:33665/data/testSimple2/core_node3/data/",
  "base_url":"https://127.0.0.1:35599/solr";,
  "node_name":"127.0.0.1:35599_solr",
  "type":"NRT",
  "force_set_state":"false",
  
"ulogDir":"hdfs://localhost.localdomain:33665/data/testSimple2/core_node3/data/tlog",
  "core":"testSimple2_shard1_replica_n1",
  "shared_storage":"true",
  "state":"down"},
"core_node5":{
  
"dataDir":"hdfs://localhost.localdomain:33665/data/testSimple2/core_node5/data/",
  "base_url":"https://127.0.0.1:42623/solr";,
  "node_name":"127.0.0.1:42623_solr",
  "type":"NRT",
  "force_set_state":"false",
  
"ulogDir":"hdfs://localhost.localdomain:33665/data/testSimple2/core_node5/data/tlog",
  "core":"testSimple2_shard1_replica_n2",
  "shared_storage":"true",
  "state":"active",
  "leader":"true"}}},
"shard2":{
  "range":"0-7fff",
  "state":"active",
  "replicas":{
"core_node7":{
  
"dataDir":"hdfs://localhost.localdomain:33665/data/testSimple2/core_node7/data/",
  "base_url":"https://127.0.0.1:35599/solr";,
  "node_name":"127.0.0.1:35599_solr",
  "type":"NRT",
  "force_set_state":"false",
  
"ulogDir":"hdfs://localhost.localdomain:33665/data/testSimple2/core_node7/data/tlog",
  "core":"testSimple2_shard2_replica_n4",
  "shared_storage":"true",
  "state":"down"},
"core_node8":{
  
"dataDir":"hdfs://localhost.localdomain:33665/data/testSimple2/core_node8/data/",
  "base_url":"https://127.0.0.1:42623/solr";,
  "node_n

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

[Policeman Jenkins Server]

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

1025 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.schema.TestICUCollationFieldDocValues

Error Message:
no conscrypt_openjdk_jni-linux-x86 in java.library.path

Stack Trace:
java.lang.UnsatisfiedLinkError: no conscrypt_openjdk_jni-linux-x86 in 
java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at 
org.conscrypt.NativeLibraryUtil.loadLibrary(NativeLibraryUtil.java:54)
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 org.conscrypt.NativeLibraryLoader$1.run(NativeLibraryLoader.java:297)
at org.conscrypt.NativeLibraryLoader$1.run(NativeLibraryLoader.java:289)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.conscrypt.NativeLibraryLoader.loadLibraryFromHelperClassloader(NativeLibraryLoader.java:289)
at 
org.conscrypt.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:262)
at org.conscrypt.NativeLibraryLoader.load(NativeLibraryLoader.java:162)
at 
org.conscrypt.NativeLibraryLoader.loadFirstAvailable(NativeLibraryLoader.java:106)
at org.conscrypt.NativeCryptoJni.init(NativeCryptoJni.java:50)
at org.conscrypt.NativeCrypto.(NativeCrypto.java:65)
at org.conscrypt.OpenSSLProvider.(OpenSSLProvider.java:60)
at org.conscrypt.OpenSSLProvider.(OpenSSLProvider.java:53)
at org.conscrypt.OpenSSLProvider.(OpenSSLProvider.java:49)
at org.apache.solr.SolrTestCaseJ4.(SolrTestCaseJ4.java:201)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:621)
Suppressed: java.lang.UnsatisfiedLinkError: no 
conscrypt_openjdk_jni-linux-x86 in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at 
org.conscrypt.NativeLibraryUtil.loadLibrary(NativeLibraryUtil.java:54)
at 
org.conscrypt.NativeLibraryLoader.loadLibraryFromCurrentClassloader(NativeLibraryLoader.java:318)
at 
org.conscrypt.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:273)
... 11 more
Suppressed: java.lang.UnsatisfiedLinkError: no conscrypt_openjdk_jni in 
java.library.path
... 24 more
Suppressed: java.lang.UnsatisfiedLinkError: no conscrypt_openjdk_jni in 
java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at 
org.conscrypt.NativeLibraryUtil.loadLibrary(NativeLibraryUtil.java:54)
at 
org.conscrypt.NativeLibraryLoader.loadLibraryFromCurrentClassloader(NativeLibraryLoader.java:318)
at 
org.conscrypt.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:273)
... 11 more
Suppressed: java.lang.UnsatisfiedLinkError: no conscrypt in 
java.library.path
... 24 more
Suppressed: java.lang.UnsatisfiedLinkError: no conscrypt in 
java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at 
org.conscrypt.NativeLibraryUtil.loadLibrary(NativeLibraryUtil.java:54)
at 
org.conscrypt.NativeLibraryLoader.loadLibraryFromCurrentClassloader(NativeLibraryLoader.java:318)
at 
org.conscrypt.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:273)
... 11 more


FAILED:  
junit.framework.TestSuite.org.apache.solr.schema.TestICUCollationFieldOptions

Error Message:
no conscrypt_openjdk_jni-linux-x86 in java.library.path

Stack Trace:
java.lang.UnsatisfiedLinkError: no conscrypt_openjdk_jni-linux-x86 in 
java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at 
org.conscrypt.NativeLibraryUtil.loadLibrary(NativeLibraryUtil.java:54)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAcc

[JENKINS] Lucene-Solr-BadApples-master-Linux (32bit/jdk1.8.0_172) - Build # 127 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/127/
Java: 32bit/jdk1.8.0_172 -server -XX:+UseG1GC

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

Error Message:
Error from server at 
https://127.0.0.1:35477/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:35477/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([EF1082387B7A83EC:17D67B0DE8631B24]: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(S

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 2182 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/2182/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  org.apache.solr.prometheus.exporter.SolrExporterTest.testExecute

Error Message:
expected:<200> but was:<404>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<404>
at 
__randomizedtesting.SeedInfo.seed([ECC0D5FDD1E598C1:DD70C7F0C3126746]: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.prometheus.exporter.SolrExporterTest.testExecute(SolrExporterTest.java:90)
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.TestCloudPivotFacet.test

Error Message:
Error from server at http://127.0.0.1:50

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11) - Build # 23271 - Still Unstable!

[Policeman Jenkins Server]

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

18 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.servlet.HttpSolrCallGetCoreTest

Error Message:
Could not find collection:collection1

Stack Trace:
java.lang.AssertionError: Could not find collection:collection1
at __randomizedtesting.SeedInfo.seed([7010187D77334A9C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155)
at 
org.apache.solr.servlet.HttpSolrCallGetCoreTest.setupCluster(HttpSolrCallGetCoreTest.java:53)
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:834)


FAILED:  
junit.framework.TestSuite.org.apache.solr.servlet.HttpSolrCallGetCoreTest

Error Message:
Could not find collection:collection1

Stack Trace:
java.lang.AssertionError: Could not find collection:collection1
at __randomizedtesting.SeedInfo.seed([7010187D77334A9C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155)
at 
org.apache.solr.servlet.HttpSolrCallGetCoreTest.setupCluster(HttpSolrCallGetCoreTest.java:53)
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.randomi

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

[Apache Jenkins Server]

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

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

[repro] Revision: 68c0774458f9d0697bf7875e677474bae07dd266

[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=RestartWhileUpdatingTest 
-Dtests.method=test -Dtests.seed=8D41AC50B277880A -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=hr -Dtests.timezone=Europe/Sarajevo -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=RestartWhileUpdatingTest 
-Dtests.seed=8D41AC50B277880A -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=hr -Dtests.timezone=Europe/Sarajevo -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
2715beb6df77d7e5795b9c111a37178527cf3831
[repro] git fetch
[repro] git checkout 68c0774458f9d0697bf7875e677474bae07dd266

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

[...truncated 3573 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.RestartWhileUpdatingTest" -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=8D41AC50B277880A -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=hr -Dtests.timezone=Europe/Sarajevo -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[repro] Failures:
[repro]   2/5 failed: org.apache.solr.cloud.RestartWhileUpdatingTest
[repro] git checkout 2715beb6df77d7e5795b9c111a37178527cf3831

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

[...truncated 5 lines...]

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

Re: SOLR: Unnecessary logging

[Walter Underwood]

I’m not a big fan of console/file magic. If that is done, there needs to be a 
big WARN at the beginning that says some log messages are suppressed because a 
console has been detected.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On Nov 27, 2018, at 6:00 PM, David Smiley  wrote:
> 
> Maybe we can have it both ways: might the distinction be done between console 
> & files?  So for example keep the console more brief, but have the log files 
> contain more logs?  Just an idea.
> 
> On Tue, Nov 27, 2018 at 8:07 AM Erick Erickson  > wrote:
> bq: Maybe the real thing to do since everyone's preferences vary is to
> have a --log-config start script option that points solr at one's
> favorite dev/testing/demo oriented logging config
> 
> There's already LOG4J_PROPS so if you have a favorite log4j config you
> want to use, just set that env variable and forget about it, does that
> work?
> 
> I spent a fair amount of time untangling the multiple log config files
> down to two, I would be loathe to add any more config files to the
> release. We could also expand the one we _do_ release for with
> comments for various options...
> 
> Best,
> Erick
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> -- 
> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley 
>  | Book: 
> http://www.solrenterprisesearchserver.com 
> 

Re: SOLR: Unnecessary logging

[David Smiley]

Maybe we can have it both ways: might the distinction be done between
console & files?  So for example keep the console more brief, but have the
log files contain more logs?  Just an idea.

On Tue, Nov 27, 2018 at 8:07 AM Erick Erickson 
wrote:

> bq: Maybe the real thing to do since everyone's preferences vary is to
> have a --log-config start script option that points solr at one's
> favorite dev/testing/demo oriented logging config
>
> There's already LOG4J_PROPS so if you have a favorite log4j config you
> want to use, just set that env variable and forget about it, does that
> work?
>
> I spent a fair amount of time untangling the multiple log config files
> down to two, I would be loathe to add any more config files to the
> release. We could also expand the one we _do_ release for with
> comments for various options...
>
> Best,
> Erick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/932/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  
org.apache.solr.cloud.api.collections.CollectionsAPIDistributedZkTest.testCoresAreDistributedAcrossNodes

Error Message:
Could not find collection : nodes_used_collection

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : 
nodes_used_collection
at 
__randomizedtesting.SeedInfo.seed([6FF831282B2A6090:BB8E44490E4E881]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:118)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:258)
at 
org.apache.solr.cloud.api.collections.CollectionsAPIDistributedZkTest.testCoresAreDistributedAcrossNodes(CollectionsAPIDistributedZkTest.java:344)
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.client.solrj.impl.CloudSolr

Re: Poll: Merge jira/http2 to master branch

[Shawn Heisey]

On 11/27/2018 3:32 AM, Uwe Schindler wrote:

I'd like to bring one thing into attention: This library conscrypt is 
ASF2-licensed, but the JAR files contain binary versions of an OpenSSL fork 
named BoringSSL. I'd recommend to check the licensing, because OpenSSL licenses 
are a bit strange (some BSD fork, also ASF2, but some code is still outdated - 
I am not sure what the fork actually uses). I have the feeling we should 
include ASF legal department.

Nevertheless, I am not 100% sure if conscrypt should really be inclued by 
default in SolrJ. As SolrJ is a client library for Solr and can be used by 
external projects, there is the problem of incompatibilities with the native C 
code included. E.g., if one uses SolrJ with IBM J9 or other Java versions 
different from openjdk. So I'd be careful. My question is: Do we really need 
that library. To me it looks like it improves speed only, or is there something 
that requires its use?


As you might know ... full and proper http/2 support with Java 8 
requires the conscrypt library.  With Java 9 or higher, the 
functionality is provided natively by Java.  If I remember right, what 
conscrypt provides that Java 8 lacks is ALPN.


If there are license issues with conscrypt, perhaps it might make sense 
to require a newer major version of Java instead ... but I think that 
upgrading the project's Java requirement to 9, 10, or 11 probably 
requires a wider discussion.  Lucene probably has no burning need for it 
right now.  I have no idea whether there are language features in Java 
9+ that we as a group are wanting to use.  Another point for 
consideration is that the effective EOL for Java 8 is fast approaching, 
and EOL dates have already come and gone for 9 and 10.


Thanks,
Shawn


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

[jira] [Commented] (SOLR-13008) JSON Document Transformer doesn't heed "indent" parameter

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-13008:
-

I had to go look at the docs to figure out what adding {{:[json]}} to a field 
in the fl param does.

The docs are not terribly clear on it, though.  The PDF I looked at (7.5) says 
that you get "the actual raw XML or JSON structure instead of just the string 
value."  But exactly what that means is not really clear to me, and there's no 
output shown for clarification of what it actually does.

The premise sounds reasonable, but my understanding of the code and the impact 
of the suggested change is pretty low.

Minor note:  The patch would fail precommit, because there's no checksum file 
for the added jar.  If I remember right, that's added with "ant jar-checksums".

> JSON Document Transformer doesn't heed "indent" parameter
> -
>
> Key: SOLR-13008
> URL: https://issues.apache.org/jira/browse/SOLR-13008
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Affects Versions: 7.5
>Reporter: Eric Pugh
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> A query like "wt=json&fl=id,subject:[json]&indent=true", will return the 
> field subject as JSON, however the indent parameter is ignored on the nested 
> JSON.   This can lead to a very wide response that you have to scroll over.  
> Often I add indent=true becasue I want to see the structure of my embedded 
> JSON text, and I need to cut'n'paste over to another editor.   This would let 
> the nested JSON object be pretty printed.



--
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] (SOLR-13018) In solr-cloud mode, It throws an error when i create a collection with schema that has fieldType containing openNLP tokenizer and filters

[Shawn Heisey (JIRA)]

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

Shawn Heisey resolved SOLR-13018.
-
   Resolution: Invalid
Fix Version/s: (was: 7.3.2)

For this project, Jira is not a support portal.  When you created this issue, 
there was a note in prominent red letters saying "This project has a user 
mailing list and an IRC channel for support. Please ensure that you have 
discussed your problem using one of those resources BEFORE creating this 
ticket."

Based on everything you've said, this is not sounding like a bug.  I believe 
that there's something you're not doing correctly.

Some things to note when you reach one of those resources:

bq. Caused by: Can't find resource 'solrconfig.xml'

It's saying that it can't find the solrconfig.xml file in the config that's in 
zookeeper.  At a minimum, your configset must include a solrconfig.xml file and 
a file for your schema as well.  Most likely the schema file will need to be 
named "managed-schema" with no extension.

bq. ERROR: Error uploading file 
/opt/solr/server/solr/configsets/xyz/conf/en-pos-maxent.bin to zookeeper path 
/configs/xyz/en-pos-maxent.bin

There will be a LOT more to this error, it could be several dozen lines long.  
If I had to guess, the problem is likely that the file in question is larger 
than the maximum node size enforced by zookeeper, which defaults to slightly 
less than one megabyte.

If after discussion on the mailing list or IRC channel it is determined that 
Solr actually does have a bug, then the problem can be explored in Jira.


> In solr-cloud mode, It throws an error when i create a collection with schema 
> that has fieldType containing openNLP tokenizer and filters
> -
>
> Key: SOLR-13018
> URL: https://issues.apache.org/jira/browse/SOLR-13018
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, SolrCloud
>Affects Versions: 7.3.1
>Reporter: Parmeshwor Thapa
>Priority: Major
>
> Here is schema for field:
> {code:java}
> 
>   
>      tokenizerModel="en-token.bin"        sentenceModel="en-sent.bin"/>
>     
>      posTaggerModel="en-pos-maxent.bin"/>
>      dictionary="en-lemmatizer.txt"/>
> 
>     
>     
>   
> 
> {code}
> I have configset with all the files(en-token.bin, en-sent.bin, ...) in same 
> directory. Using that configset i can successfully create Solr Core in 
> Standalone mode.
> But With Solr cloud (two instances in separate servers orchestrated by  
> zookeeper) i have the same configset in both servers and i try to create  a  
> collection, it is throwing me an error which doesn't make any sense to me.
> {code:java}
>  $ bin/solr create -p 8984 -c  xyz -n xyz_conf -d xyz_conf
> ... ERROR: Failed to create collection 'xyz' due to: 
> {example1.com:8984_solr=org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at https://example2.com:8984/solr: Error CREATEing SolrCore 
> 'xyz_shard1_replica_n1': Unable to create core [xyz_shard1_replica_n1] Caused 
> by: Can't find resource 'solrconfig.xml' in classpath or '/configs/xyz', 
> cwd=/opt/solr-7.3.1/server}
> {code}
>  
>   
> Note: uploading configset to zookeeper also fails with error
> {code:java}
> $ bin/solr create -c xyz  -n xyz_conf -d xyz_conf
> ...
> —
> ERROR: Error uploading file 
> /opt/solr/server/solr/configsets/xyz/conf/en-pos-maxent.bin to zookeeper path 
> /configs/xyz/en-pos-maxent.bin
> {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] (SOLR-13014) URI Too Long with large streaming expressions in SolrJ

[JIRA]

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

Jan Høydahl updated SOLR-13014:
---
Fix Version/s: 7.7
   master (8.0)

> URI Too Long with large streaming expressions in SolrJ
> --
>
> Key: SOLR-13014
> URL: https://issues.apache.org/jira/browse/SOLR-13014
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, streaming expressions
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: master (8.0), 7.7
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> For very large expressions (e.g. with a complex search string) we'll hit the 
> max HTTP GET limit since SolrJ does not enforce POST for all expressions. 
> This goes at least for {{FacetStream}}, {{StatsStream}} and 
> {{TimeSeriesStream}}, and I'll link a Pull Request fixing these three.
> Here is an example of a stack trace when using TimeSeriesStream with a very 
> large expression: [https://gist.github.com/ea626cf1ec579daaf253aeb805d1532c]
> The fix is simply to use {{new QueryRequest(parameters, 
> SolrRequest.METHOD.POST);}} to explicitly force POST.
> See also solr-user thread 
> [http://lucene.472066.n3.nabble.com/Streaming-Expressions-GET-vs-POST-td4415044.html]



--
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-SmokeRelease-7.x - Build # 385 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/385/

No tests ran.

Build Log:
[...truncated 23451 lines...]
[asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
 [java] Processed 2443 links (1994 relative) to 3213 anchors in 247 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/changes

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/solr-7.7.0.tgz
 into 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr.tgz.unpacked

generate-maven-artifacts:

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:c

[JENKINS] Lucene-Solr-http2-Linux (64bit/jdk1.8.0_172) - Build # 6 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-http2-Linux/6/
Java: 64bit/jdk1.8.0_172 -XX:-UseCompressedOops -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:40001/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.14.v20181114  
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at https://127.0.0.1:40001/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.14.v20181114




at 
__randomizedtesting.SeedInfo.seed([9CD17D1647CC9E31:5E66417E448C6E49]: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:196)
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.jav

[jira] [Commented] (SOLR-12753) Async logging ring buffer and OOM error

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-12753:
---

[~ab]WDYT is a good length for the max size? The current patch tops it off at 
10K. Too large? Too small?

> Async logging ring buffer and OOM error
> ---
>
> Key: SOLR-12753
> URL: https://issues.apache.org/jira/browse/SOLR-12753
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Affects Versions: 7.5
>Reporter: Andrzej Bialecki 
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12753.patch
>
>
> I’m using a simulated environment for autoscaling tests, which may create 
> some pretty degenerate cases (like collections with 50,000 replicas and 
> Policy calculations over these, times 500 nodes).
> I noticed that when I turned on debug logging I occasionally would get an OOM 
> error, and the heap dump showed that the biggest objects were a bunch of 
> extremely large strings in the async logger’s ring buffer. These strings were 
> admittedly extremely large (million chars or so) but the previously used sync 
> logging didn’t have any issue with them, because they were consumed one by 
> one.
> For sure, Solr should not attempt to be logging multi-megabyte data. But I 
> also feel like the framework could perhaps help here by enforcing large but 
> sane limits on maximum size of log messages.



--
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 #510: LUCENE-8573: Use FutureArrays#mismatch in BKD...

[cbuescher]

GitHub user cbuescher opened a pull request:

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

LUCENE-8573: Use FutureArrays#mismatch in BKDWriter

As LUCENE-8573 describes, BKDWriter uses loops in many places to find the 
first mismatching byte between multiple arrays. This change replaces that with 
FutureArrays#mismatch.

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

$ git pull https://github.com/cbuescher/lucene-solr fix-8573

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

https://github.com/apache/lucene-solr/pull/510.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 #510


commit 827c176611cac8bfab4996188e6c4bdba66a58c2
Author: Christoph Büscher 
Date:   2018-11-27T16:41:58Z

LUCENE-8573: Use FutureArrays#mismatch in BKDWriter




---

-
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-11) - Build # 23270 - Still Unstable!

[Policeman Jenkins Server]

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

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

Error Message:
Could not find collection:multicollection2

Stack Trace:
java.lang.AssertionError: Could not find collection:multicollection2
at 
__randomizedtesting.SeedInfo.seed([348A70BD8AC1E292:CF9DE30DD3963525]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.checkCollectionParameters(CloudSolrClientTest.java:575)
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.

[JENKINS] Lucene-Solr-http2-MacOSX (64bit/jdk-9) - Build # 1 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-http2-MacOSX/1/
Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseSerialGC

10 tests failed.
FAILED:  
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testPasswordProtected

Error Message:
class org.conscrypt.Platform (in unnamed module @0x590ec79b) cannot access 
class sun.security.x509.AlgorithmId (in module java.base) because module 
java.base does not export sun.security.x509 to unnamed module @0x590ec79b

Stack Trace:
java.lang.IllegalAccessError: class org.conscrypt.Platform (in unnamed module 
@0x590ec79b) cannot access class sun.security.x509.AlgorithmId (in module 
java.base) because module java.base does not export sun.security.x509 to 
unnamed module @0x590ec79b
at 
__randomizedtesting.SeedInfo.seed([FFCB29B24F4FD566:F96EAD49B17685BC]:0)
at org.conscrypt.Platform.oidToAlgorithmName(Platform.java:525)
at 
org.conscrypt.OpenSSLX509Certificate.getSigAlgName(OpenSSLX509Certificate.java:313)
at 
org.conscrypt.OpenSSLX509Certificate.verifyInternal(OpenSSLX509Certificate.java:392)
at 
org.conscrypt.OpenSSLX509Certificate.verify(OpenSSLX509Certificate.java:413)
at 
java.base/javax.crypto.JarVerifier.testSignatures(JarVerifier.java:735)
at java.base/javax.crypto.JarVerifier.access$300(JarVerifier.java:38)
at java.base/javax.crypto.JarVerifier$1.run(JarVerifier.java:192)
at java.base/javax.crypto.JarVerifier$1.run(JarVerifier.java:167)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/javax.crypto.JarVerifier.(JarVerifier.java:166)
at 
java.base/javax.crypto.ProviderVerifier.verify(ProviderVerifier.java:128)
at 
java.base/javax.crypto.JceSecurity.verifyProvider(JceSecurity.java:189)
at 
java.base/javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:215)
at 
java.base/javax.crypto.JceSecurity.canUseProvider(JceSecurity.java:229)
at java.base/javax.crypto.Cipher.getInstance(Cipher.java:527)
at 
org.apache.poi.poifs.crypt.CryptoFunctions.getCipher(CryptoFunctions.java:241)
at 
org.apache.poi.poifs.crypt.CryptoFunctions.getCipher(CryptoFunctions.java:205)
at 
org.apache.poi.poifs.crypt.agile.AgileDecryptor.hashInput(AgileDecryptor.java:269)
at 
org.apache.poi.poifs.crypt.agile.AgileDecryptor.verifyPassword(AgileDecryptor.java:114)
at 
org.apache.tika.parser.microsoft.OfficeParser.parse(OfficeParser.java:220)
at 
org.apache.tika.parser.microsoft.OfficeParser.parse(OfficeParser.java:131)
at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
at 
org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:143)
at 
org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:228)
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2541)
at 
org.apache.solr.util.TestHarness.queryAndResponse(TestHarness.java:365)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.loadLocalFromHandler(ExtractingRequestHandlerTest.java:766)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.loadLocal(ExtractingRequestHandlerTest.java:773)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testPasswordProtected(ExtractingRequestHandlerTest.java:721)
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.a

[jira] [Created] (SOLR-13020) Additional Hooks in SolrEventListener

[Kevin Jia (JIRA)]

Kevin Jia created SOLR-13020:


 Summary: Additional Hooks in SolrEventListener
 Key: SOLR-13020
 URL: https://issues.apache.org/jira/browse/SOLR-13020
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Plugin system
Reporter: Kevin Jia


Add more hooks in SolrEventListener to allow for greater user customization. 
Proposed hooks are: 


public void postCoreConstruct(SolrCore core);
public void preAddDoc(AddUpdateCommand cmd);
public void postAddDoc(AddUpdateCommand cmd);
public void preDelete(DeleteUpdateCommand cmd);
public void postDelete(DeleteUpdateCommand cmd);



--
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-http2 - Build # 1 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-http2/1/

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

Error Message:
Expected new active leader null Live Nodes: [127.0.0.1:33182_solr, 
127.0.0.1:35927_solr, 127.0.0.1:37212_solr] Last available state: 
DocCollection(raceDeleteReplica_true//collections/raceDeleteReplica_true/state.json/14)={
   "pullReplicas":"0",   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node3":{   "core":"raceDeleteReplica_true_shard1_replica_n1", 
  "base_url":"https://127.0.0.1:37528/solr";,   
"node_name":"127.0.0.1:37528_solr",   "state":"down",   
"type":"NRT",   "leader":"true"}, "core_node6":{   
"core":"raceDeleteReplica_true_shard1_replica_n5",   
"base_url":"https://127.0.0.1:37528/solr";,   
"node_name":"127.0.0.1:37528_solr",   "state":"down",   
"type":"NRT"}, "core_node4":{   
"core":"raceDeleteReplica_true_shard1_replica_n2",   
"base_url":"https://127.0.0.1:35927/solr";,   
"node_name":"127.0.0.1:35927_solr",   "state":"down",   
"type":"NRT",   "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:33182_solr, 127.0.0.1:35927_solr, 127.0.0.1:37212_solr]
Last available state: 
DocCollection(raceDeleteReplica_true//collections/raceDeleteReplica_true/state.json/14)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node3":{
  "core":"raceDeleteReplica_true_shard1_replica_n1",
  "base_url":"https://127.0.0.1:37528/solr";,
  "node_name":"127.0.0.1:37528_solr",
  "state":"down",
  "type":"NRT",
  "leader":"true"},
"core_node6":{
  "core":"raceDeleteReplica_true_shard1_replica_n5",
  "base_url":"https://127.0.0.1:37528/solr";,
  "node_name":"127.0.0.1:37528_solr",
  "state":"down",
  "type":"NRT"},
"core_node4":{
  "core":"raceDeleteReplica_true_shard1_replica_n2",
  "base_url":"https://127.0.0.1:35927/solr";,
  "node_name":"127.0.0.1:35927_solr",
  "state":"down",
  "type":"NRT",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([AAFD898163A334B5:C0EBE8510B517E7F]: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:223)
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(ThreadLeak

Solr Test Fixing Update

[Mark Miller]

Just spent a lot of time traveling, but I'm just about ready to make my
first large commit towards fixing the Solr tests.

First I'll commit to master and then in a day or two I'll commit to 7x as
well.

This commit will be a huge step forward, but it is still just the start.

ant test should work a lot better for everyone (even without excluding
badapples), but not every test has been beasted and made solid. I expect
Jenkins email failures to reduce but not go away yet at all. This commit
likely fixes hundreds of possible fails, but many long tail fails remain.

I will start tackling the full hardening effort by package (hopefully with
other volunteers) as the next step.

There is a lot to do beyond that to finish and maintain solid tests, but I
have a plan that I will continue to execute on that I think we get the
project there.

- Mark

[GitHub] lucene-solr issue #482: LUCENE-8539: fix some typos and improve style in Tes...

[diegoceccarelli]

Github user diegoceccarelli commented on the issue:

https://github.com/apache/lucene-solr/pull/482
  
Thanks @mikemccand, now precommit seems happy, I squashed and rebased to 
the latest master. 



---

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-9) - Build # 4952 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4952/
Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

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([FAE9094F597B0E9E:F06AB6E214C005C4]: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:576)
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 
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:844)


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

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([FAE9094F597B0E9E:C367B00F7684C76

[jira] [Created] (SOLR-13019) Fix typo in MailEntityProcessor.java

[Tommy Marshment-Howell (JIRA)]

Tommy Marshment-Howell created SOLR-13019:
-

 Summary: Fix typo in MailEntityProcessor.java
 Key: SOLR-13019
 URL: https://issues.apache.org/jira/browse/SOLR-13019
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: contrib - DataImportHandler
Reporter: Tommy Marshment-Howell


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



--
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-10817) Update Ref Guide coverage of schema.xml vs managed-schema

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-10817:
-
Fix Version/s: (was: 7.0)
   master (8.0)

> Update Ref Guide coverage of schema.xml vs managed-schema
> -
>
> Key: SOLR-10817
> URL: https://issues.apache.org/jira/browse/SOLR-10817
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Major
> Fix For: master (8.0)
>
>
> When the managed-schema was made the default, we made mostly only minor 
> changes to the Ref Guide to make sure managed-schema was mentioned in the 
> same places schema.xml had been mentioned so users didn't get the impression 
> they were different files or perhaps had a different structure. At that time, 
> Hoss had this to say about it:
> {quote}
> There are still a TON of references to schema.xml that i did not touch 
> however, because they are on pages side by side with explicit & specific 
> examples of schema.xml XML declarations (ie: how to define a field, or field 
> type) ... we need to holistically decide what we want to do with this
> {quote}
> What we should do now is revamp the schema coverage throughout the Ref Guide. 
> Where appropriate we should add examples of using the Schema API in addition 
> to (or instead of) only discussing manual edits. Additionally, we should 
> consolidate the pages on Managed Schema, Schemaless mode, schema editing, the 
> structure of the file, etc. This info is a bit scattered for something that 
> is central to a successful implementation of Solr.



--
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] (SOLR-12497) Add ref guide docs for Hadoop Credential Provider based SSL/TLS store password source.

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-12497.
--
Resolution: Fixed

Thanks Jan, I fixed the typo, resolving the issue now. Thanks Mano for review 
and writing it up to start with!

> Add ref guide docs for Hadoop Credential Provider based SSL/TLS store 
> password source.
> --
>
> Key: SOLR-12497
> URL: https://issues.apache.org/jira/browse/SOLR-12497
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.4
>Reporter: Mano Kovacs
>Assignee: Cassandra Targett
>Priority: Minor
> Fix For: 7.6, master (8.0)
>
> Attachments: SOLR-12497.patch
>
>
> Document configuration added in SOLR-10783.



--
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-12497) Add ref guide docs for Hadoop Credential Provider based SSL/TLS store password source.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12497:


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

SOLR-12497: fix typo


> Add ref guide docs for Hadoop Credential Provider based SSL/TLS store 
> password source.
> --
>
> Key: SOLR-12497
> URL: https://issues.apache.org/jira/browse/SOLR-12497
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.4
>Reporter: Mano Kovacs
>Assignee: Cassandra Targett
>Priority: Minor
> Fix For: 7.6, master (8.0)
>
> Attachments: SOLR-12497.patch
>
>
> Document configuration added in SOLR-10783.



--
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-12497) Add ref guide docs for Hadoop Credential Provider based SSL/TLS store password source.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12497:


Commit ad753020aee6b63b155fe439af6f562afe88d5c1 in lucene-solr's branch 
refs/heads/branch_7_6 from [~ctargett]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ad75302 ]

SOLR-12497: fix typo


> Add ref guide docs for Hadoop Credential Provider based SSL/TLS store 
> password source.
> --
>
> Key: SOLR-12497
> URL: https://issues.apache.org/jira/browse/SOLR-12497
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.4
>Reporter: Mano Kovacs
>Assignee: Cassandra Targett
>Priority: Minor
> Fix For: 7.6, master (8.0)
>
> Attachments: SOLR-12497.patch
>
>
> Document configuration added in SOLR-10783.



--
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-12497) Add ref guide docs for Hadoop Credential Provider based SSL/TLS store password source.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12497:


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

SOLR-12497: fix typo


> Add ref guide docs for Hadoop Credential Provider based SSL/TLS store 
> password source.
> --
>
> Key: SOLR-12497
> URL: https://issues.apache.org/jira/browse/SOLR-12497
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.4
>Reporter: Mano Kovacs
>Assignee: Cassandra Targett
>Priority: Minor
> Fix For: 7.6, master (8.0)
>
> Attachments: SOLR-12497.patch
>
>
> Document configuration added in SOLR-10783.



--
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: Jenkins test report improvements: Suspicious (Recent) Failure Rates

[Dawid Weiss]

Hi Chris!

Right. All you say is true here. JUnit 4.x wasn't clear on the
specification of how such multiple failures should be handled in the
first place. Some things were wrapped in "multiple-failure" exception,
which didn't seem right to me. When I wrote the dedicated runner there
was a lot of guessing involved, including XML reports (this bit not
even part of JUnit, but Apache Ant and Apache Maven).

> Junit even logs a warning about this when it sees us doing it...

It's actually the listener that I wrote that emits this log. Which
leads me to say that if it's more helpful we could emit a different
type of report from the runner (in addition to what Jenkins consumes).
Internally, listeners receive each and every exception separately so
they can serialize them in a more palatable manner. The XML listener
is just one implementation:

https://github.com/randomizedtesting/randomizedtesting/blob/master/junit4-ant/src/main/java/com/carrotsearch/ant/tasks/junit4/listeners/antxml/AntXmlReport.java

Ideally, the new JUnit (5) provides a more modern and structured
framework to build on top of... lots of hacks wouldn't be needed if we
switched over. I just don't have the time to take care of it right
now, sorry about that.

> Reading the logs (as a person), we can see that during the initial "ant
> test" BasicZkTest's lone test method PASSED, but there were 4 suite level
> errors reported...
> [...]
> below showing what the test report says about BasicZkTest -- note there is
> a single "suite" block for this class, regardless of being run multiple
> times.

That's because tools assume each class can be initialized once. The
"tests.dups" isn't even implemented as part of the runner (because of
this kind of problems); it was added to Ant build script later on. The
XMLs written from the runner will have separate section for each
repeated suite (I believe... didn't check and it was quite a while
ago); the aggregation of these individual XMLs down the chain in
jenkins is screwed up somewhere.

D.

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

Could I get some eyes on SOLR-13008?

[Eric Pugh]

Hi all,

I’ve been using the [json] field transformer to simplify my client code when 
consuming JSON data, and noticed that visually parsing through a complex JSON 
object is hard to do.   SOLR-13008 is a patch that pretty prints the JSON 
response when indent=true, which is currently ignored.   

I’d love to get some feedback on it: 
https://issues.apache.org/jira/browse/SOLR-13008.  

Thanks!
Eric


___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com  | 
My Free/Busy   
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 


This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 
attachments are marked as such.

[jira] [Updated] (SOLR-13018) In solr-cloud mode, It throws an error when i create a collection with schema that has fieldType containing openNLP tokenizer and filters

[Parmeshwor Thapa (JIRA)]

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

Parmeshwor Thapa updated SOLR-13018:

Description: 
Here is schema for field:
{code:java}

  
    
    
    
    

    
    
  

{code}
I have configset with all the files(en-token.bin, en-sent.bin, ...) in same 
directory. Using that configset i can successfully create Solr Core in 
Standalone mode.

But With Solr cloud (two instances in separate servers orchestrated by  
zookeeper) i have the same configset in both servers and i try to create  a  
collection, it is throwing me an error which doesn't make any sense to me.
{code:java}
 $ bin/solr create -p 8984 -c  xyz -n xyz_conf -d xyz_conf
... ERROR: Failed to create collection 'xyz' due to: 
{example1.com:8984_solr=org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
 from server at https://example2.com:8984/solr: Error CREATEing SolrCore 
'xyz_shard1_replica_n1': Unable to create core [xyz_shard1_replica_n1] Caused 
by: Can't find resource 'solrconfig.xml' in classpath or '/configs/xyz', 
cwd=/opt/solr-7.3.1/server}


{code}
 

  

Note: uploading configset to zookeeper also fails with error
{code:java}
$ bin/solr create -c xyz  -n xyz_conf -d xyz_conf
...

—

ERROR: Error uploading file 
/opt/solr/server/solr/configsets/xyz/conf/en-pos-maxent.bin to zookeeper path 
/configs/xyz/en-pos-maxent.bin
{code}
 

  was:
Here is schema for field:
{code:java}

  
    
    
    
    

    
    
  

{code}
I have configset with all the files(en-token.bin, en-sent.bin, ...) in same 
directory. Using that configset i can successfully create Solr Core in 
Standalone mode.

But With Solr cloud (two instances in separate servers orchestrated by  
zookeeper) i have the same configset in both servers and i try to create  a  
collection, it is throwing me an error which doesn't make any sense to me.
{code:java}
 $ bin/solr create -p 8984 -c  xyz -n xyz_conf -d xyz_conf
... ERROR: Failed to create collection 'xyz' due to: 
{example1.com:8984_solr=org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
 from server at https://example2.com:8984/solr: Error CREATEing SolrCore 
'xyz_shard1_replica_n1': Unable to create core [xyz_shard1_replica_n1] Caused 
by: Can't find resource 'solrconfig.xml' in classpath or '/configs/xyz', 
cwd=/opt/solr-7.3.1/server}
{code}
 

  

Note: uploading configset to zookeeper also fails with error
{code:java}
$ bin/solr create -c xyz  -n xyz_conf -d xyz_conf
...

—

ERROR: Error uploading file 
/opt/solr/server/solr/configsets/xyz/conf/en-pos-maxent.bin to zookeeper path 
/configs/xyz/en-pos-maxent.bin
{code}
 


> In solr-cloud mode, It throws an error when i create a collection with schema 
> that has fieldType containing openNLP tokenizer and filters
> -
>
> Key: SOLR-13018
> URL: https://issues.apache.org/jira/browse/SOLR-13018
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, SolrCloud
>Affects Versions: 7.3.1
>Reporter: Parmeshwor Thapa
>Priority: Major
> Fix For: 7.3.2
>
>
> Here is schema for field:
> {code:java}
> 
>   
>      tokenizerModel="en-token.bin"        sentenceModel="en-sent.bin"/>
>     
>      posTaggerModel="en-pos-maxent.bin"/>
>      dictionary="en-lemmatizer.txt"/>
> 
>     
>     
>   
> 
> {code}
> I have configset with all the files(en-token.bin, en-sent.bin, ...) in same 
> directory. Using that configset i can successfully create Solr Core in 
> Standalone mode.
> But With Solr cloud (two instances in separate servers orchestrated by  
> zookeeper) i have the same configset in both servers and i try to create  a  
> collection, it is throwing me an error which doesn't make any sense to me.
> {code:java}
>  $ bin/solr create -p 8984 -c  xyz -n xyz_conf -d xyz_conf
> ... ERROR: Failed to create collection 'xyz' due to: 
> {example1.com:8984_solr=org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at https://example2.com:8984/solr: Error CREATEing SolrCore 
> 'xyz_shard1_replica_n1': Unable to create core [xyz_shard1_replica_n1] Caused 
> by: Can't find resource 'solrconfig.xml' in classpath or '/configs/xyz', 
> cwd=/opt/solr-7.3.1/server}
> {code}
>  
>   
> Note: uploading configset to zookeeper also fails with error
> {code:java}
> $ bin/solr create -c xyz  -n xyz_conf -d xyz_conf
> ...
> —
> ERROR: Error uploading file 
> /opt/solr/server/solr/configsets/xyz/conf/en-pos-maxent.bin to zookeeper path 
> /configs/xyz/en-pos-maxent.bin
> {code}
>  



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

-

[jira] [Updated] (SOLR-13018) In solr-cloud mode, It throws an error when i create a collection with schema that has fieldType containing openNLP tokenizer and filters

[Parmeshwor Thapa (JIRA)]

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

Parmeshwor Thapa updated SOLR-13018:

Description: 
Here is schema for field:
{code:java}

  
    
    
    
    

    
    
  

{code}
I have configset with all the files(en-token.bin, en-sent.bin, ...) in same 
directory. Using that configset i can successfully create Solr Core in 
Standalone mode.

But With Solr cloud (two instances in separate servers orchestrated by  
zookeeper) i have the same configset in both servers and i try to create  a  
collection, it is throwing me an error which doesn't make any sense to me.
{code:java}
 $ bin/solr create -p 8984 -c  xyz -n xyz_conf -d xyz_conf
... ERROR: Failed to create collection 'xyz' due to: 
{example1.com:8984_solr=org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
 from server at https://example2.com:8984/solr: Error CREATEing SolrCore 
'xyz_shard1_replica_n1': Unable to create core [xyz_shard1_replica_n1] Caused 
by: Can't find resource 'solrconfig.xml' in classpath or '/configs/xyz', 
cwd=/opt/solr-7.3.1/server}
{code}
 

  

Note: uploading configset to zookeeper also fails with error
{code:java}
$ bin/solr create -c xyz  -n xyz_conf -d xyz_conf
...

—

ERROR: Error uploading file 
/opt/solr/server/solr/configsets/xyz/conf/en-pos-maxent.bin to zookeeper path 
/configs/xyz/en-pos-maxent.bin
{code}
 

  was:
Here is schema for field:


  
    
    
    
    
    
    
    
  
 

 

I have configset with all the files(en-token.bin, en-sent.bin, ...) in same 
directory. Using that configset i can successfully create Solr Core in 
Standalone mode.

But With Solr cloud (two instances in separate servers orchestrated by  
zookeeper) i have the same configset in both servers and i try to create  a  
collection, it is throwing me an error which doesn't make any sense to me.

 $ bin/solr create -p 8984 -c  xyz -n xyz_conf -d xyz_conf

...

ERROR: Failed to create collection 'xyz' due to: 
\{example1.com:8984_solr=org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
 from server at https://example2.com:8984/solr: Error CREATEing SolrCore 
'xyz_shard1_replica_n1': Unable to create core [xyz_shard1_replica_n1] Caused 
by: Can't find resource 'solrconfig.xml' in classpath or '/configs/xyz', 
cwd=/opt/solr-7.3.1/server}

 

 

Note: uploading configset to zookeeper also fails with error

$ bin/solr create -c xyz  -n xyz_conf -d xyz_conf

...

---

ERROR: Error uploading file 
/opt/solr/server/solr/configsets/xyz/conf/en-pos-maxent.bin to zookeeper path 
/configs/xyz/en-pos-maxent.bin

 

 


> In solr-cloud mode, It throws an error when i create a collection with schema 
> that has fieldType containing openNLP tokenizer and filters
> -
>
> Key: SOLR-13018
> URL: https://issues.apache.org/jira/browse/SOLR-13018
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, SolrCloud
>Affects Versions: 7.3.1
>Reporter: Parmeshwor Thapa
>Priority: Major
> Fix For: 7.3.2
>
>
> Here is schema for field:
> {code:java}
> 
>   
>      tokenizerModel="en-token.bin"        sentenceModel="en-sent.bin"/>
>     
>      posTaggerModel="en-pos-maxent.bin"/>
>      dictionary="en-lemmatizer.txt"/>
> 
>     
>     
>   
> 
> {code}
> I have configset with all the files(en-token.bin, en-sent.bin, ...) in same 
> directory. Using that configset i can successfully create Solr Core in 
> Standalone mode.
> But With Solr cloud (two instances in separate servers orchestrated by  
> zookeeper) i have the same configset in both servers and i try to create  a  
> collection, it is throwing me an error which doesn't make any sense to me.
> {code:java}
>  $ bin/solr create -p 8984 -c  xyz -n xyz_conf -d xyz_conf
> ... ERROR: Failed to create collection 'xyz' due to: 
> {example1.com:8984_solr=org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at https://example2.com:8984/solr: Error CREATEing SolrCore 
> 'xyz_shard1_replica_n1': Unable to create core [xyz_shard1_replica_n1] Caused 
> by: Can't find resource 'solrconfig.xml' in classpath or '/configs/xyz', 
> cwd=/opt/solr-7.3.1/server}
> {code}
>  
>   
> Note: uploading configset to zookeeper also fails with error
> {code:java}
> $ bin/solr create -c xyz  -n xyz_conf -d xyz_conf
> ...
> —
> ERROR: Error uploading file 
> /opt/solr/server/solr/configsets/xyz/conf/en-pos-maxent.bin to zookeeper path 
> /configs/xyz/en-pos-maxent.bin
> {code}
>  



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

-

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

[Policeman Jenkins Server]

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

4 tests failed.
FAILED:  org.apache.solr.cloud.TestTlogReplica.testRecovery

Error Message:
Can not find doc 7 in https://127.0.0.1:35701/solr

Stack Trace:
java.lang.AssertionError: Can not find doc 7 in https://127.0.0.1:35701/solr
at 
__randomizedtesting.SeedInfo.seed([47B8CEB8D8462E35:8648B714F516E492]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.TestTlogReplica.checkRTG(TestTlogReplica.java:902)
at 
org.apache.solr.cloud.TestTlogReplica.testRecovery(TestTlogReplica.java:567)
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 
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:844)


FAILED:  org.apache.solr.cloud.TestTlogReplica.testRecovery

Error Message:
Can not find doc 7 in https://127.0.0.1:33419/solr

Stack Trace:
java.lang.AssertionErr

[jira] [Created] (SOLR-13018) In solr-cloud mode, It throws an error when i create a collection with schema that has fieldType containing openNLP tokenizer and filters

[Parmeshwor Thapa (JIRA)]

Parmeshwor Thapa created SOLR-13018:
---

 Summary: In solr-cloud mode, It throws an error when i create a 
collection with schema that has fieldType containing openNLP tokenizer and 
filters
 Key: SOLR-13018
 URL: https://issues.apache.org/jira/browse/SOLR-13018
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Admin UI, SolrCloud
Affects Versions: 7.3.1
Reporter: Parmeshwor Thapa
 Fix For: 7.3.2


Here is schema for field:


  
    
    
    
    
    
    
    
  
 

 

I have configset with all the files(en-token.bin, en-sent.bin, ...) in same 
directory. Using that configset i can successfully create Solr Core in 
Standalone mode.

But With Solr cloud (two instances in separate servers orchestrated by  
zookeeper) i have the same configset in both servers and i try to create  a  
collection, it is throwing me an error which doesn't make any sense to me.

 $ bin/solr create -p 8984 -c  xyz -n xyz_conf -d xyz_conf

...

ERROR: Failed to create collection 'xyz' due to: 
\{example1.com:8984_solr=org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
 from server at https://example2.com:8984/solr: Error CREATEing SolrCore 
'xyz_shard1_replica_n1': Unable to create core [xyz_shard1_replica_n1] Caused 
by: Can't find resource 'solrconfig.xml' in classpath or '/configs/xyz', 
cwd=/opt/solr-7.3.1/server}

 

 

Note: uploading configset to zookeeper also fails with error

$ bin/solr create -c xyz  -n xyz_conf -d xyz_conf

...

---

ERROR: Error uploading file 
/opt/solr/server/solr/configsets/xyz/conf/en-pos-maxent.bin to zookeeper path 
/configs/xyz/en-pos-maxent.bin

 

 



--
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 #504: SOLR-13008 First cut of indenting JSON formatted fie...

[epugh]

Github user epugh commented on the issue:

https://github.com/apache/lucene-solr/pull/504
  
I added some nicer indenting.  For a JSON block like:
```json
{
"am I a teapot":true,
"lyrics":[
"I'm a little teapot","Short and stout","Here is my handle","Here is my 
spout"
]
}
```
with `indent=false`:

![noindent](https://user-images.githubusercontent.com/22395/49103707-15150180-f24a-11e8-806a-22233b90b754.png)

However, with 'indent=true`:

![indented](https://user-images.githubusercontent.com/22395/49103724-1e9e6980-f24a-11e8-8023-6cff3ca3f7d4.png)

I'd love some feedback, as I am relying on Jackson to parse the XML or JSON 
string, and their is some assumptions on indentation levels that I made...



---

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

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

[Apache Jenkins Server]

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

[...truncated 44 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-Tests-7.x/1041/consoleText

[repro] Revision: b5c42f2b2fb9fe586b62a5e4e1d7a9c3982b6262

[repro] Repro line:  ant test  -Dtestcase=TestSolrCloudWithKerberosAlt 
-Dtests.method=testBasics -Dtests.seed=BAC6CE027EB26802 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=sq-AL 
-Dtests.timezone=America/Kentucky/Monticello -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=CloudSolrClientTest 
-Dtests.method=testRouting -Dtests.seed=FC00F65F3A8712DE -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=bg -Dtests.timezone=America/Argentina/Jujuy 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
c2cac887702f9efc0a6bf75cd9f1e78f730c2c4f
[repro] git fetch
[repro] git checkout b5c42f2b2fb9fe586b62a5e4e1d7a9c3982b6262

[...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]   TestSolrCloudWithKerberosAlt
[repro]solr/solrj
[repro]   CloudSolrClientTest
[repro] ant compile-test

[...truncated 3586 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestSolrCloudWithKerberosAlt" -Dtests.showOutput=onerror  
-Dtests.seed=BAC6CE027EB26802 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=sq-AL -Dtests.timezone=America/Kentucky/Monticello 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

[...truncated 68 lines...]
[repro] ant compile-test

[...truncated 454 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.CloudSolrClientTest" -Dtests.showOutput=onerror  
-Dtests.seed=FC00F65F3A8712DE -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=bg -Dtests.timezone=America/Argentina/Jujuy -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.cloud.TestSolrCloudWithKerberosAlt
[repro]   3/5 failed: org.apache.solr.client.solrj.impl.CloudSolrClientTest
[repro] git checkout c2cac887702f9efc0a6bf75cd9f1e78f730c2c4f

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

[...truncated 5 lines...]

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

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.TestTlogReplica.testRemoveLeader

Error Message:
Replica core_node4 not up to date after 10 seconds expected:<1> but was:<0>

Stack Trace:
java.lang.AssertionError: Replica core_node4 not up to date after 10 seconds 
expected:<1> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([F1A0250930D7D4AE:68E0E26D775EB4E4]: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.apache.solr.cloud.TestTlogReplica.waitForNumDocsInAllReplicas(TestTlogReplica.java:777)
at 
org.apache.solr.cloud.TestTlogReplica.waitForNumDocsInAllReplicas(TestTlogReplica.java:765)
at 
org.apache.solr.cloud.TestTlogReplica.doReplaceLeader(TestTlogReplica.java:386)
at 
org.apache.solr.cloud.TestTlogReplica.testRemoveLeader(TestTlogReplica.java:320)
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.

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 389 - Still unstable

[Apache Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.HdfsRestartWhileUpdatingTest.test

Error Message:
There are still nodes recoverying - waited for 320 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 320 
seconds
at 
__randomizedtesting.SeedInfo.seed([64E46779FF6ECF5F:ECB058A35192A2A7]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:185)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:920)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForThingsToLevelOut(AbstractFullDistribZkTestBase.java:1477)
at 
org.apache.solr.cloud.RestartWhileUpdatingTest.test(RestartWhileUpdatingTest.java:145)
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.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1010)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.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.TestRuleIgnoreTestSuite

[JENKINS-EA] Lucene-Solr-7.x-Windows (64bit/jdk-12-ea+12) - Build # 902 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/902/
Java: 64bit/jdk-12-ea+12 -XX:+UseCompressedOops -XX:+UseSerialGC

5 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.TriggerSetPropertiesIntegrationTest.testSetProperties

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([1C5C2BB79FE71C86:7738FCFE2CCA8902]: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.cloud.autoscaling.TriggerSetPropertiesIntegrationTest.testSetProperties(TriggerSetPropertiesIntegrationTest.java:111)
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 
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:  
org.apache.solr.cloud.autoscaling.TriggerSetPropertiesIntegrationTest.testSetProperties

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([1C5C2BB79FE71C86:7738FCFE2CCA8902]:0)
at org.j

[jira] [Commented] (SOLR-6117) Replication command=fetchindex always return success.

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-6117:
---

Most recent attached patch is a slight update of Shalin's.  I'd hoped to add a 
lot more tests with this that trigger the various failure conditions, but it's 
hard to reproduce many of them via JUnit.  Also looked at adding unit tests for 
ReplicationHandler directly, but it relies heavily on SolrCore, which is final 
which makes mocking/stubbing difficult as well.  If anyone sees a way to get 
more coverage on this without major surgery, I'd love to hear it.

The current patch makes sure that we never advertise a response as status=OK 
falsely, so it's just a bugfix and should be safe to include in branch_7x from 
a breaking-change perspective.  There's a lot of other problems with the 
replication handler responses that would require breaking changes.  
Specifically:
* "status" is only present on some responses.  Ideally it should be present on 
all /replication responses so that clients can rely on it being there.
* "status" is used inconsistently.  Some uses give it an enum-like value that 
clients could key off of, others treat it like a "message" field and just give 
it random error messages
* when errors occur, the "message" and "exception" fields are used 
inconsistently.  Ideally if an error occurs there would always be a message, 
and sometimes there would also be an exception.
* many of the error-cases involving argument-validation set the status field 
properly but return with the wrong HTTP status (200). (i.e. they should throw a 
SolrException).

I plan on working some of these out soon in a larger commit that can be put on 
master.

> Replication command=fetchindex always return success.
> -
>
> Key: SOLR-6117
> URL: https://issues.apache.org/jira/browse/SOLR-6117
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 4.6
>Reporter: Raintung Li
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-6117.patch, SOLR-6117.patch, SOLR-6117.patch, 
> SOLR-6117.txt
>
>
> Replication API command=fetchindex do fetch the index. while occur the error, 
> still give success response. 
> API should return the right status, especially WAIT parameter is 
> true.(synchronous).



--
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-6117) Replication command=fetchindex always return success.

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski updated SOLR-6117:
--
Attachment: SOLR-6117.patch

> Replication command=fetchindex always return success.
> -
>
> Key: SOLR-6117
> URL: https://issues.apache.org/jira/browse/SOLR-6117
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 4.6
>Reporter: Raintung Li
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-6117.patch, SOLR-6117.patch, SOLR-6117.patch, 
> SOLR-6117.txt
>
>
> Replication API command=fetchindex do fetch the index. while occur the error, 
> still give success response. 
> API should return the right status, especially WAIT parameter is 
> true.(synchronous).



--
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: Jenkins test report improvements: Suspicious (Recent) Failure Rates

[Chris Hostetter]

: bq. if the jenkins build re-runs a TestCase 5 times, there's still
: only one section for that suite
: 
: I don't know about Jenkins XML, but this behavior is quite all right.
: Suite exceptions are either from static class init blocks or from
: "outside of test" scopes (like rule initialization, cleanup,
: Before/AfterClass hooks, etc.). These are performed once per class,

They are performed once each time a test class is "run", but:

1) there may be multiple "suite level" failures reported for a single 
"run" of a suite -- which was the first time of confusing/problematic 
situation (even before the "repro" logic was added to some jenkins builds) 
that made it possible to see a suite level test failure rate > 100% from a 
single run of a test -- because there might be multiple suite level 
problems (IIRC one eample is an exception thrown during an @AfterClass 
*and* leaked threads are reported).

2) Add to that the fact that single jenkins job might run the same suite 
multiple times (because it's trying to repro a seed) and you can get even 
more "suite level" failures from a single test class in a single jenkins 
job -- but the test report doesn't contain any info about any many times 
the suite was "run" ... all of the method results & suite level 
failures for a single class *name* are aggregated into a single "suite" 
entry in the test report regardless of which run the failure came from.

Junit even logs a warning about this when it sees us doing it...

   [junit4] Duplicate suite name used with XML reports: 
org.apache.solr.cloud.BasicZkTest. This may confuse tools that process XML 
reports. Set 'ignoreDuplicateSuites' to true to skip this message.


Here's just one example of why the suite level failure rates can be wacky...


Looking at this jenkins job..

https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-master-Linux/23269/

Reading the logs (as a person), we can see that during the initial "ant 
test" BasicZkTest's lone test method PASSED, but there were 4 suite level 
errors reported...

   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=BasicZkTest 
-Dtests.seed=130E39C045A2E030 -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=sr -Dtests.timezone=Afr
ica/El_Aaiun -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.00s J0 | BasicZkTest (suite) <<<
   ...
   [junit4] Completed [317/837 (2!)] on J0 in 86.92s, 1 test, 4 errors <<< 
FAILURES!


Later in that same jenkins job, that repro line was retried - and the test 
ran and passed w/o any suite level failures -- but note the xml snippet 
below showing what the test report says about BasicZkTest -- note there is 
a single "suite" block for this class, regardless of being run multiple 
times.

Ideally I'd like to report that there were 4 total "runs" of the class, 
and *1* of them had suite level failureS ... but the report doesn't make 
it clear that the suite ran 4 times, let alone that these failures all 
came from a single run.

So for now -- the summary reports I generated can only make silly 
assumptions, leading to things like 200% suite failure rates.


https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-master-Linux/23269/testReport/api/xml?tree=suites%5Bcases%5BclassName,name,status%5D%5D

  ...
  

  org.apache.solr.cloud.BasicZkTest
  testBasic
  PASSED


  org.apache.solr.cloud.BasicZkTest
  testBasic
  PASSED


  org.apache.solr.cloud.BasicZkTest
  testBasic
  PASSED


  org.apache.solr.cloud.BasicZkTest
  testBasic
  PASSED


  junit.framework.TestSuite
  org.apache.solr.cloud.BasicZkTest
  FAILED


  junit.framework.TestSuite
  org.apache.solr.cloud.BasicZkTest
  FAILED


  junit.framework.TestSuite
  org.apache.solr.cloud.BasicZkTest
  FAILED


  junit.framework.TestSuite
  org.apache.solr.cloud.BasicZkTest
  FAILED

  







-Hoss
http://www.lucidworks.com/

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

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

[Policeman Jenkins Server]

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

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

Error Message:
Error from server at http://127.0.0.1:43433/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:43433/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([10D01FFA76A3025E:D267239275E3F226]: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 
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.carrotsea

Re: Lucene/Solr 7.6

[Nicholas Knize]

Hello all. A quick update on 7.6. It looks like all blockers have been
resolved. Let me know if I missed any and if there aren't any objections
I'll plan to build a 7.6 RC on Thursday of this week.

Thanks!



On Wed, Nov 21, 2018 at 1:34 PM Cassandra Targett 
wrote:

> Doc changes are still fine, Andrzej. I still have a couple things to do
> for the Ref Guide also.
>
> On Wed, Nov 21, 2018 at 12:09 PM Andrzej Białecki  wrote:
>
>> Hi Nicholas,
>>
>> If it’s ok I would like to merge a small fix to the Ref Guide, spotted by
>> Christine in SOLR-9856.
>>
>> On 1 Nov 2018, at 21:38, Nicholas Knize  wrote:
>>
>> Hi all,
>>
>> To follow up from our discussion on the 8.0 thread, I would like to cut
>> the 7.6 branch on either Tuesday or Wednesday of next week. Since this
>> implies feature freeze I went ahead and had a look at some of the issues
>> that are labeled for 7.6.
>>
>> It looks like we only have one active issue listed as a blocker for Solr.
>> The upgrade notes in SOLR-12927
>> 
>>
>> For Lucene we have five active issues (each with a patch provided) listed
>> as blockers targeted for 7.6.
>>
>> If there are any other issues that need to land before cutting the
>> branch, and they are not already labeled, please either mark them as
>> blockers accordingly or let me know prior to cutting the branch next
>> Tuesday or Wednesday.
>>
>> Thank you!
>>
>> - Nick
>> --
>>
>> Nicholas Knize, Ph.D., GISP
>> Geospatial Software Guy  |  Elasticsearch
>> Apache Lucene Committer
>> nkn...@apache.org
>>
>>
>>
>>
>> —
>>
>> Andrzej Białecki
>>
>> --

Nicholas Knize, Ph.D., GISP
Geospatial Software Guy  |  Elasticsearch
Apache Lucene Committer
nkn...@apache.org

[jira] [Commented] (LUCENE-8573) BKDWriter should use FutureArrays#mismatch

[Nicholas Knize (JIRA)]

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

Nicholas Knize commented on LUCENE-8573:


That would be great [~cbuescher]

> BKDWriter should use FutureArrays#mismatch
> --
>
> Key: LUCENE-8573
> URL: https://issues.apache.org/jira/browse/LUCENE-8573
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> In a number of places, BKDWriter tries to find the first mismatching byte 
> between multiple arrays with a for loop. It could use the safer 
> FutureArrays#mismatch instead.



--
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-8575) Improve toString() in SegmentInfo

[Namgyu Kim (JIRA)]

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

Namgyu Kim updated LUCENE-8575:
---
Attachment: LUCENE-8575.patch

> Improve toString() in SegmentInfo
> -
>
> Key: LUCENE-8575
> URL: https://issues.apache.org/jira/browse/LUCENE-8575
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Namgyu Kim
>Priority: Major
> Attachments: LUCENE-8575.patch
>
>
> I saw the following code in SegmentInfo class.
> {code:java}
> // TODO: we could append toString of attributes() here?
> {code}
> Of course, we can.
>  
> So I wrote a code for that part.
> {code:java}
> public String toString(int delCount) {
>   StringBuilder s = new StringBuilder();
>   s.append(name).append('(').append(version == null ? "?" : 
> version).append(')').append(':');
>   char cfs = getUseCompoundFile() ? 'c' : 'C';
>   s.append(cfs);
>   s.append(maxDoc);
>   if (delCount != 0) {
> s.append('/').append(delCount);
>   }
>   if (indexSort != null) {
> s.append(":[indexSort=");
> s.append(indexSort);
> s.append(']');
>   }
>   // New Code
>   if (!diagnostics.isEmpty()) {
> s.append(":[diagnostics=");
> for (Map.Entry entry : diagnostics.entrySet())
>   
> s.append("<").append(entry.getKey()).append(",").append(entry.getValue()).append(">,");
> s.setLength(s.length() - 1);
> s.append(']');
>   }
>   // New Code
>   if (!attributes.isEmpty()) {
> s.append(":[attributes=");
> for (Map.Entry entry : attributes.entrySet())
>   
> s.append("<").append(entry.getKey()).append(",").append(entry.getValue()).append(">,");
> s.setLength(s.length() - 1);
> s.append(']');
>   }
>   return s.toString();
> }
> {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] [Created] (LUCENE-8575) Improve toString() in SegmentInfo

[Namgyu Kim (JIRA)]

Namgyu Kim created LUCENE-8575:
--

 Summary: Improve toString() in SegmentInfo
 Key: LUCENE-8575
 URL: https://issues.apache.org/jira/browse/LUCENE-8575
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/index
Reporter: Namgyu Kim


I saw the following code in SegmentInfo class.
{code:java}
// TODO: we could append toString of attributes() here?
{code}
Of course, we can.

 

So I wrote a code for that part.
{code:java}
public String toString(int delCount) {
  StringBuilder s = new StringBuilder();
  s.append(name).append('(').append(version == null ? "?" : 
version).append(')').append(':');
  char cfs = getUseCompoundFile() ? 'c' : 'C';
  s.append(cfs);

  s.append(maxDoc);

  if (delCount != 0) {
s.append('/').append(delCount);
  }

  if (indexSort != null) {
s.append(":[indexSort=");
s.append(indexSort);
s.append(']');
  }

  // New Code
  if (!diagnostics.isEmpty()) {
s.append(":[diagnostics=");
for (Map.Entry entry : diagnostics.entrySet())
  
s.append("<").append(entry.getKey()).append(",").append(entry.getValue()).append(">,");
s.setLength(s.length() - 1);
s.append(']');
  }

  // New Code
  if (!attributes.isEmpty()) {
s.append(":[attributes=");
for (Map.Entry entry : attributes.entrySet())
  
s.append("<").append(entry.getKey()).append(",").append(entry.getValue()).append(">,");
s.setLength(s.length() - 1);
s.append(']');
  }

  return s.toString();
}
{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] (SOLR-13017) SolrInputField.setValue method should not use supplied collection as backing value.

[Charles Sanders (JIRA)]

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

Charles Sanders updated SOLR-13017:
---
Component/s: SolrJ

> SolrInputField.setValue method should not use supplied collection as backing 
> value.
> ---
>
> Key: SOLR-13017
> URL: https://issues.apache.org/jira/browse/SOLR-13017
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Charles Sanders
>Priority: Minor
> Attachments: SOLR-13017.patch
>
>
> The setValue method in SolrInputField takes an argument of Object.  If the 
> supplied object is a collection, then the collection is used as the backing 
> value for the field.  This can cause unexpected results when the collection 
> is used to initialize two or more different fields.
> Consider the example where a list of values 'a', 'b', 'c' is used to 
> initialize two fields in a SolrInputDocument.
> {noformat}
> List lst = new ArrayList<>();
> lst.add("a");
> lst.add("b");
> lst.add("c");
> 
> SolrInputDocument sid = new SolrInputDocument();
> sid.addField("alpha", lst);
> sid.addField("beta", lst);
> .
> .  {add more fields to doc}
> .
> sid.addField("beta", "blah");  // add another value to field 'beta'
> {noformat}
> Because the same list is used to initialize both fields 'alpha' and 'beta', 
> they not only contain the same values, but point to the same instance of the 
> list.  Therefore, if an additional value is added to one of the fields, both 
> will contain the value.
> In the example provided, the user would expect field 'alpha' to contain 
> values 'a', 'b', 'c'.  While field 'beta' should contain fields 'a', 'b', 'c' 
> and 'blah'.  But that is not the case.  Both fields point to the same 
> instance of the list, so if a new value is added to either field, the list is 
> updated and both fields will contain the same values ('a', 'b', 'c', 'blah').
> This is not a bug, but the intended logic of the method based on the method 
> comment.
> {noformat}
> /**
>* Set the value for a field.  Arrays will be converted to a collection. If
>* a collection is given, then that collection will be used as the backing
>* collection for the values.
>*/
> {noformat}
> This jira is a request to improve the logic of the method by not using the 
> supplied collection as the backing value for the field.  But rather, create a 
> new collection and add the values from the supplied collection to the new 
> collection.  This way the field is not backed by the actual instance of the 
> supplied collection, but its values only.



--
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-12984) The search Streaming Expression should properly support and push down paging when using the /select handler

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-12984:
--
Description: 
Currently the search Streaming Expression doesn't properly support paging even 
when going to the /select handler. This is due to very old implementation 
decisions that were geared towards supporting streaming entire result sets from 
the /export handler. It's time to change this behavior the so the search 
expression can be used to handle typical paging scenarios.

This ticket will maintain the same behavior for when qt=/export, but will push 
down 'rows' and 'start' parameters when using /select handler. 

  was:
Currently the search Streaming Expression doesn't properly support paging even 
when going to the /select handler. This is due to very old implementation 
decisions that were geared towards supporting streaming entire result sets from 
the /export handler. It's time to change this behavior the so the search 
expression can be used to handle typical paging scenarios.

This ticket will maintain the same behavior for when qt=/export, but will push 
down 'rows' and 'offset' parameters when using /select handler. 


> The search Streaming Expression should properly support and push down paging 
> when using the /select handler
> ---
>
> Key: SOLR-12984
> URL: https://issues.apache.org/jira/browse/SOLR-12984
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-12984.patch, SOLR-12984.patch, SOLR-12984.patch, 
> SOLR-12984.patch
>
>
> Currently the search Streaming Expression doesn't properly support paging 
> even when going to the /select handler. This is due to very old 
> implementation decisions that were geared towards supporting streaming entire 
> result sets from the /export handler. It's time to change this behavior the 
> so the search expression can be used to handle typical paging scenarios.
> This ticket will maintain the same behavior for when qt=/export, but will 
> push down 'rows' and 'start' parameters when using /select handler. 



--
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-12984) The search Streaming Expression should properly support and push down paging when using the /select handler

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12984:


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

SOLR-12984: The search Streaming Expression should properly support and push 
down paging when using the /select handler


> The search Streaming Expression should properly support and push down paging 
> when using the /select handler
> ---
>
> Key: SOLR-12984
> URL: https://issues.apache.org/jira/browse/SOLR-12984
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-12984.patch, SOLR-12984.patch, SOLR-12984.patch, 
> SOLR-12984.patch
>
>
> Currently the search Streaming Expression doesn't properly support paging 
> even when going to the /select handler. This is due to very old 
> implementation decisions that were geared towards supporting streaming entire 
> result sets from the /export handler. It's time to change this behavior the 
> so the search expression can be used to handle typical paging scenarios.
> This ticket will maintain the same behavior for when qt=/export, but will 
> push down 'rows' and 'offset' parameters when using /select handler. 



--
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-12984) The search Streaming Expression should properly support and push down paging when using the /select handler

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-12984:
--
Fix Version/s: master (8.0)

> The search Streaming Expression should properly support and push down paging 
> when using the /select handler
> ---
>
> Key: SOLR-12984
> URL: https://issues.apache.org/jira/browse/SOLR-12984
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-12984.patch, SOLR-12984.patch, SOLR-12984.patch, 
> SOLR-12984.patch
>
>
> Currently the search Streaming Expression doesn't properly support paging 
> even when going to the /select handler. This is due to very old 
> implementation decisions that were geared towards supporting streaming entire 
> result sets from the /export handler. It's time to change this behavior the 
> so the search expression can be used to handle typical paging scenarios.
> This ticket will maintain the same behavior for when qt=/export, but will 
> push down 'rows' and 'offset' parameters when using /select handler. 



--
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-5211) updating parent as childless makes old children orphans

[Frank Kelly (JIRA)]

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

Frank Kelly commented on SOLR-5211:
---

Many thanks to all who contributed to this fix - it is very welcome! 

> updating parent as childless makes old children orphans
> ---
>
> Key: SOLR-5211
> URL: https://issues.apache.org/jira/browse/SOLR-5211
> Project: Solr
>  Issue Type: Sub-task
>  Components: update
>Affects Versions: 4.5, 6.0
>Reporter: Mikhail Khludnev
>Assignee: David Smiley
>Priority: Blocker
> Fix For: master (8.0)
>
> Attachments: SOLR-5211.patch, SOLR-5211.patch, SOLR-5211.patch, 
> SOLR-5211.patch, SOLR-5211.patch
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> if I have parent with children in the index, I can send update omitting 
> children. as a result old children become orphaned. 
> I suppose separate \_root_ fields makes much trouble. I propose to extend 
> notion of uniqueKey, and let it spans across blocks that makes updates 
> unambiguous.  
> WDYT? Do you like to see a test proves this issue?



--
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: SOLR: Unnecessary logging

[Erick Erickson]

bq: Maybe the real thing to do since everyone's preferences vary is to
have a --log-config start script option that points solr at one's
favorite dev/testing/demo oriented logging config

There's already LOG4J_PROPS so if you have a favorite log4j config you
want to use, just set that env variable and forget about it, does that
work?

I spent a fair amount of time untangling the multiple log config files
down to two, I would be loathe to add any more config files to the
release. We could also expand the one we _do_ release for with
comments for various options...

Best,
Erick

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

[jira] [Resolved] (SOLR-5211) updating parent as childless makes old children orphans

[David Smiley (JIRA)]

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

David Smiley resolved SOLR-5211.

Resolution: Fixed

> updating parent as childless makes old children orphans
> ---
>
> Key: SOLR-5211
> URL: https://issues.apache.org/jira/browse/SOLR-5211
> Project: Solr
>  Issue Type: Sub-task
>  Components: update
>Affects Versions: 4.5, 6.0
>Reporter: Mikhail Khludnev
>Assignee: David Smiley
>Priority: Blocker
> Fix For: master (8.0)
>
> Attachments: SOLR-5211.patch, SOLR-5211.patch, SOLR-5211.patch, 
> SOLR-5211.patch, SOLR-5211.patch
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> if I have parent with children in the index, I can send update omitting 
> children. as a result old children become orphaned. 
> I suppose separate \_root_ fields makes much trouble. I propose to extend 
> notion of uniqueKey, and let it spans across blocks that makes updates 
> unambiguous.  
> WDYT? Do you like to see a test proves this issue?



--
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-13017) SolrInputField.setValue method should not use supplied collection as backing value.

[Charles Sanders (JIRA)]

Charles Sanders created SOLR-13017:
--

 Summary: SolrInputField.setValue method should not use supplied 
collection as backing value.
 Key: SOLR-13017
 URL: https://issues.apache.org/jira/browse/SOLR-13017
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Charles Sanders


The setValue method in SolrInputField takes an argument of Object.  If the 
supplied object is a collection, then the collection is used as the backing 
value for the field.  This can cause unexpected results when the collection is 
used to initialize two or more different fields.

Consider the example where a list of values 'a', 'b', 'c' is used to initialize 
two fields in a SolrInputDocument.

{noformat}
List lst = new ArrayList<>();
lst.add("a");
lst.add("b");
lst.add("c");

SolrInputDocument sid = new SolrInputDocument();
sid.addField("alpha", lst);
sid.addField("beta", lst);
.
.  {add more fields to doc}
.
sid.addField("beta", "blah");  // add another value to field 'beta'
{noformat}

Because the same list is used to initialize both fields 'alpha' and 'beta', 
they not only contain the same values, but point to the same instance of the 
list.  Therefore, if an additional value is added to one of the fields, both 
will contain the value.

In the example provided, the user would expect field 'alpha' to contain values 
'a', 'b', 'c'.  While field 'beta' should contain fields 'a', 'b', 'c' and 
'blah'.  But that is not the case.  Both fields point to the same instance of 
the list, so if a new value is added to either field, the list is updated and 
both fields will contain the same values ('a', 'b', 'c', 'blah').

This is not a bug, but the intended logic of the method based on the method 
comment.
{noformat}
/**
   * Set the value for a field.  Arrays will be converted to a collection. If
   * a collection is given, then that collection will be used as the backing
   * collection for the values.
   */
{noformat}
This jira is a request to improve the logic of the method by not using the 
supplied collection as the backing value for the field.  But rather, create a 
new collection and add the values from the supplied collection to the new 
collection.  This way the field is not backed by the actual instance of the 
supplied collection, but its values only.



--
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 #509: Fix typo in MailEntityProcessor.java

[tommymh]

GitHub user tommymh opened a pull request:

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

Fix typo in MailEntityProcessor.java



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

$ git pull https://github.com/tommymh/lucene-solr master

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

https://github.com/apache/lucene-solr/pull/509.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 #509


commit 2b55cb05d09766c4e52ca485cf3a6d85e8879e18
Author: Tommy Marshment-Howell 
Date:   2018-11-27T15:51:47Z

Fix typo in MailEntityProcessor.java

commit d5c3136fc2cd57c1e7883005c41391ca43262dd4
Author: Tommy Marshment-Howell 
Date:   2018-11-27T15:52:11Z

Merge branch 'master' of https://github.com/tommymh/lucene-solr




---

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

[jira] [Commented] (SOLR-5211) updating parent as childless makes old children orphans

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-5211:
---

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

SOLR-5211: fix test


> updating parent as childless makes old children orphans
> ---
>
> Key: SOLR-5211
> URL: https://issues.apache.org/jira/browse/SOLR-5211
> Project: Solr
>  Issue Type: Sub-task
>  Components: update
>Affects Versions: 4.5, 6.0
>Reporter: Mikhail Khludnev
>Assignee: David Smiley
>Priority: Blocker
> Fix For: master (8.0)
>
> Attachments: SOLR-5211.patch, SOLR-5211.patch, SOLR-5211.patch, 
> SOLR-5211.patch, SOLR-5211.patch
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> if I have parent with children in the index, I can send update omitting 
> children. as a result old children become orphaned. 
> I suppose separate \_root_ fields makes much trouble. I propose to extend 
> notion of uniqueKey, and let it spans across blocks that makes updates 
> unambiguous.  
> WDYT? Do you like to see a test proves this issue?



--
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-12984) The search Streaming Expression should properly support and push down paging when using the /select handler

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-12984:
--
Attachment: SOLR-12984.patch

> The search Streaming Expression should properly support and push down paging 
> when using the /select handler
> ---
>
> Key: SOLR-12984
> URL: https://issues.apache.org/jira/browse/SOLR-12984
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: SOLR-12984.patch, SOLR-12984.patch, SOLR-12984.patch, 
> SOLR-12984.patch
>
>
> Currently the search Streaming Expression doesn't properly support paging 
> even when going to the /select handler. This is due to very old 
> implementation decisions that were geared towards supporting streaming entire 
> result sets from the /export handler. It's time to change this behavior the 
> so the search expression can be used to handle typical paging scenarios.
> This ticket will maintain the same behavior for when qt=/export, but will 
> push down 'rows' and 'offset' parameters when using /select handler. 



--
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-http2-Linux (64bit/jdk-9.0.4) - Build # 5 - Still Failing!

[Policeman Jenkins Server]

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

18 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithDelegationTokens

Error Message:
Error starting up MiniSolrCloudCluster

Stack Trace:
java.lang.Exception: Error starting up MiniSolrCloudCluster
at __randomizedtesting.SeedInfo.seed([8C186FDB90935477]:0)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.checkForExceptions(MiniSolrCloudCluster.java:523)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:252)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:196)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:123)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.startup(TestSolrCloudWithDelegationTokens.java:70)
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$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:844)
Suppressed: java.lang.NoClassDefFoundError: Could not initialize class 
javax.crypto.JarVerifier
at 
java.base/javax.crypto.ProviderVerifier.verify(ProviderVerifier.java:128)
at 
java.base/javax.crypto.JceSecurity.verifyProvider(JceSecurity.java:189)
at 
java.base/javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:215)
at 
java.base/javax.crypto.JceSecurity.canUseProvider(JceSecurity.java:229)
at 
java.base/javax.crypto.KeyGenerator.nextSpi(KeyGenerator.java:363)
at 
java.base/javax.crypto.KeyGenerator.(KeyGenerator.java:176)
at 
java.base/javax.crypto.KeyGenerator.getInstance(KeyGenerator.java:244)
at 
org.apache.hadoop.security.token.SecretManager.(SecretManager.java:143)
at 
org.apache.hadoop.security.token.delegation.AbstractDelegationTokenSecretManager.(AbstractDelegationTokenSecretManager.java:104)
at 
org.apache.hadoop.security.token.delegation.ZKDelegationTokenSecretManager.(ZKDelegationTokenSecretManager.java:138)
at 
org.apache.hadoop.security.token.delegation.web.DelegationTokenManager$ZKSecretManager.(DelegationTokenManager.java:95)
at 
org.apache.hadoop.security.token.delegation.web.DelegationTokenManager.(DelegationTokenManager.java:116)
at 
org.apache.hadoop.security.token.delegation.web.DelegationTokenAuthenticationHandler.initTokenManager(DelegationTokenAuthenticationHandler.java:148)
at 
org.apache.hadoop.security.token.delegation.web.DelegationTokenAu

[jira] [Commented] (LUCENE-8573) BKDWriter should use FutureArrays#mismatch

[JIRA]

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

Christoph Büscher commented on LUCENE-8573:
---

Hi, I'd like to work on this as a first issue.

> BKDWriter should use FutureArrays#mismatch
> --
>
> Key: LUCENE-8573
> URL: https://issues.apache.org/jira/browse/LUCENE-8573
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> In a number of places, BKDWriter tries to find the first mismatching byte 
> between multiple arrays with a for loop. It could use the safer 
> FutureArrays#mismatch instead.



--
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: SOLR: Unnecessary logging

[Gus Heck]

Startup logging that happens just on startup should err on the side of
verbosity. I like the ulimit checks even if they are sometimes irrelevant
on my dev systems, the lib listing also sounds useful. Of course truly
useful things like the jetty jsp message should be eliminated. Default
logging generally should be verbose, and tuning it down when needed is just
part of tuning the system imho. Once an event has passed un-logged, it's
gone and the clue to what happened is missing and the developer has to
spend time to even know what log to turn on, if it's even reproducible. If
we do anything, it ought to be some sort of logging profiles (beyond -q and
-v I suppose), but it seems to me we have lots of configurability there
already https://lucene.apache.org/solr/guide/7_5/configuring-logging.html.

Maybe the real thing to do since everyone's preferences vary is to have a
--log-config start script option that points solr at one's favorite
dev/testing/demo oriented logging config. This would also be nice for cases
where you want the logging config to live outside of the install where
someone can easily play with it.

-Gus

On Wed, Nov 21, 2018 at 5:50 PM Uwe Schindler  wrote:

> No it won't deduplicate. It is actually worse: Every class would be a
> different class instance per core, just with same name (they won't even
> compare equals to each other). This why you have classloader, so you can
> have same class name in different parts of app. OSGI... The expressions
> module does the same. Every compiled Lucene expression has the same class
> name, just in a different classloader.
>
> So every core has its own copy of all classes. That's a common problem for
> users with many cores each of those having Tika configured per core only...
>
> Uwe
>
> Am November 21, 2018 10:23:29 PM UTC schrieb Shawn Heisey <
> apa...@elyograg.org>:
>>
>> On 11/21/2018 1:40 AM, Jan Høydahl wrote:
>>
>>> It is super easy to change the log level of one particular class or
>>> package
>>> selectively, that's why we have log4j2.xml and also the Admin's
>>> Logging levels menu.
>>> The occational need to see all of the 150 jar files loaded on startup
>>> should not be
>>> solved by spewing out that for first-time users of Solr who really
>>> just care for whether
>>> the server started OK or not.
>>>
>>
>> If somebody's got a config that loads 150 jars, I really do think that
>> having that info in the log would be useful information.  That's a LOT
>> of jars, and it could be vital for troubleshooting a classloader problem
>> with one jar -- need to be able to tell whether it has been loaded or not.
>>
>> It definitely shouldn't be default to have Jetty log its jar loading.  I
>> just want to know how to make it do so, for situations that require very
>> in-depth study.
>>
>> A user who's got 20 cores and each of them is loading the same 10 jars
>> with  config ... IMHO that would ALSO be useful information to be
>> able to see in the default log.  Without it, the user will probably have
>> absolutely no idea that they have 200 jar loads.  (when that happens,
>> does Java realize that the classloader is loading the same jars and
>> eliminate duplicates in memory?)
>>
>> Thanks,
>> Shawn
>> --
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>


-- 
http://www.the111shift.com

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23269/
Java: 64bit/jdk1.8.0_172 -XX:+UseCompressedOops -XX:+UseParallelGC

15 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.BasicZkTest

Error Message:
SolrCore.getOpenCount()==2

Stack Trace:
java.lang.RuntimeException: SolrCore.getOpenCount()==2
at __randomizedtesting.SeedInfo.seed([130E39C045A2E030]:0)
at org.apache.solr.util.TestHarness.close(TestHarness.java:380)
at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:802)
at 
org.apache.solr.cloud.AbstractZkTestCase.azt_afterClass(AbstractZkTestCase.java:147)
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$7.evaluate(RandomizedRunner.java:898)
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:  junit.framework.TestSuite.org.apache.solr.cloud.BasicZkTest

Error Message:
SolrCore.getOpenCount()==2

Stack Trace:
java.lang.RuntimeException: SolrCore.getOpenCount()==2
at __randomizedtesting.SeedInfo.seed([130E39C045A2E030]:0)
at org.apache.solr.util.TestHarness.close(TestHarness.java:380)
at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:802)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:297)
at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
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$7.evaluate(RandomizedRunner.java:898)
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.carrotsearc

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 2180 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/2180/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.StreamDecoratorTest.testParallelCommitStream

Error Message:
expected:<5> but was:<2>

Stack Trace:
java.lang.AssertionError: expected:<5> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([8AC7DD5785FD26A6:AA2DBF5719BCCBEA]: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.io.stream.StreamDecoratorTest.testParallelCommitStream(StreamDecoratorTest.java:3037)
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)




Build Log:
[...truncated 16499 lines...]
   [junit4] Suite: org.apache.solr.clie

[jira] [Resolved] (SOLR-12927) Ref Guide: Upgrade Notes for 7.6

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-12927.
--
Resolution: Fixed

> Ref Guide: Upgrade Notes for 7.6
> 
>
> Key: SOLR-12927
> URL: https://issues.apache.org/jira/browse/SOLR-12927
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Blocker
> Fix For: 7.6
>
> Attachments: SOLR-12927.patch
>
>
> Add Upgrade Notes from CHANGES and any other relevant changes worth 
> mentioning.



--
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-5211) updating parent as childless makes old children orphans

[mosh (JIRA)]

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

mosh updated SOLR-5211:
---
Attachment: SOLR-5211.patch

> updating parent as childless makes old children orphans
> ---
>
> Key: SOLR-5211
> URL: https://issues.apache.org/jira/browse/SOLR-5211
> Project: Solr
>  Issue Type: Sub-task
>  Components: update
>Affects Versions: 4.5, 6.0
>Reporter: Mikhail Khludnev
>Assignee: David Smiley
>Priority: Blocker
> Fix For: master (8.0)
>
> Attachments: SOLR-5211.patch, SOLR-5211.patch, SOLR-5211.patch, 
> SOLR-5211.patch, SOLR-5211.patch
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> if I have parent with children in the index, I can send update omitting 
> children. as a result old children become orphaned. 
> I suppose separate \_root_ fields makes much trouble. I propose to extend 
> notion of uniqueKey, and let it spans across blocks that makes updates 
> unambiguous.  
> WDYT? Do you like to see a test proves this issue?



--
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-5211) updating parent as childless makes old children orphans

[mosh (JIRA)]

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

mosh commented on SOLR-5211:


[~dsmiley],

I fixed RootFieldTest, and double checked that it passes with both 
useRootSchema as true and false.
I did not see when I pulled the latest master some of the schema names had 
changed.
I uploaded a new patch.

> updating parent as childless makes old children orphans
> ---
>
> Key: SOLR-5211
> URL: https://issues.apache.org/jira/browse/SOLR-5211
> Project: Solr
>  Issue Type: Sub-task
>  Components: update
>Affects Versions: 4.5, 6.0
>Reporter: Mikhail Khludnev
>Assignee: David Smiley
>Priority: Blocker
> Fix For: master (8.0)
>
> Attachments: SOLR-5211.patch, SOLR-5211.patch, SOLR-5211.patch, 
> SOLR-5211.patch, SOLR-5211.patch
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> if I have parent with children in the index, I can send update omitting 
> children. as a result old children become orphaned. 
> I suppose separate \_root_ fields makes much trouble. I propose to extend 
> notion of uniqueKey, and let it spans across blocks that makes updates 
> unambiguous.  
> WDYT? Do you like to see a test proves this issue?



--
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-5211) updating parent as childless makes old children orphans

[mosh (JIRA)]

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

mosh updated SOLR-5211:
---
Attachment: (was: SOLR-5211.patch)

> updating parent as childless makes old children orphans
> ---
>
> Key: SOLR-5211
> URL: https://issues.apache.org/jira/browse/SOLR-5211
> Project: Solr
>  Issue Type: Sub-task
>  Components: update
>Affects Versions: 4.5, 6.0
>Reporter: Mikhail Khludnev
>Assignee: David Smiley
>Priority: Blocker
> Fix For: master (8.0)
>
> Attachments: SOLR-5211.patch, SOLR-5211.patch, SOLR-5211.patch, 
> SOLR-5211.patch, SOLR-5211.patch
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> if I have parent with children in the index, I can send update omitting 
> children. as a result old children become orphaned. 
> I suppose separate \_root_ fields makes much trouble. I propose to extend 
> notion of uniqueKey, and let it spans across blocks that makes updates 
> unambiguous.  
> WDYT? Do you like to see a test proves this issue?



--
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 # 3150 - Still Unstable!

[Policeman Jenkins Server]

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

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

Error Message:
Error from server at http://127.0.0.1:43911/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:43911/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([7C92EC88FAE77CE7:BE25D0E0F9A78C9F]: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 
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 
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(SystemProper

[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk1.8.0) - Build # 957 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/957/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([266B01F7D5EAE381:1FE5B8B7FA152A7F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration(IndexSizeTriggerTest.java:320)
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)




Build Log:
[...truncated 14353 lines...]
   [junit4] Suite: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest
   [junit4]   2> Creating dataDir: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/solr/build/solr-core/test/J0/temp/solr.cloud.autoscaling.I

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

[Apache Jenkins Server]

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

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

Error Message:
max version bucket seed not updated after recovery!

Stack Trace:
java.lang.AssertionError: max version bucket seed not updated after recovery!
at 
__randomizedtesting.SeedInfo.seed([CC0F0D81016CFDF1:445B325BAF909009]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:290)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:131)
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.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1010)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.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 j

[jira] [Commented] (SOLR-12209) add Paging Streaming Expression

[mosh (JIRA)]

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

mosh commented on SOLR-12209:
-

ping [~joel.bernstein]?

> add Paging Streaming Expression
> ---
>
> Key: SOLR-12209
> URL: https://issues.apache.org/jira/browse/SOLR-12209
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: mosh
>Priority: Major
> Attachments: SOLR-12209.patch, SOLR-12209.patch, SOLR-12209.patch
>
>
> Currently the closest streaming expression that allows some sort of 
> pagination is top.
> I propose we add a new streaming expression, which is based on the 
> RankedStream class to add offset to the stream. currently it can only be done 
> in code by reading the stream until the desired offset is reached.
> The new expression will be used as such:
> {{paging(rows=3, search(collection1, q="*:*", qt="/export", 
> fl="id,a_s,a_i,a_f", sort="a_f desc, a_i desc"), sort="a_f asc, a_i asc", 
> start=100)}}
> {{this will offset the returned stream by 100 documents}}
>  
> [~joel.bernstein] what to you think?



--
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-8517) TestRandomChains.testRandomChainsWithLargeStrings failure

[ASF subversion and git services (JIRA)]

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

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

Commit e5ab0d41effbad5d65bc3e5e0a5133459317fa14 in lucene-solr's branch 
refs/heads/branch_7x from Michael Sokolov
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e5ab0d4 ]

LUCENE-8517: do not wrap FixedShingleFilter with conditional in TestRandomChains


> TestRandomChains.testRandomChainsWithLargeStrings failure
> -
>
> Key: LUCENE-8517
> URL: https://issues.apache.org/jira/browse/LUCENE-8517
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Reporter: Steve Rowe
>Priority: Major
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> From 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2828/consoleText], 
> reproduces for me on Java8:
> {noformat}
> Checking out Revision 216f10026b86627750e133fe24ce6a750c470695 
> (refs/remotes/origin/branch_7x)
> [...]
> [java-info] java version "10.0.1"
> [java-info] OpenJDK Runtime Environment (10.0.1+10, Oracle Corporation)
> [java-info] OpenJDK 64-Bit Server VM (10.0.1+10, Oracle Corporation)
> [java-info] Test args: [-XX:-UseCompressedOops -XX:+UseConcMarkSweepGC]
> [...]
>[junit4] Suite: org.apache.lucene.analysis.core.TestRandomChains
>[junit4]   2> Exception from random analyzer: 
>[junit4]   2> charfilters=
>[junit4]   2>   
> org.apache.lucene.analysis.charfilter.MappingCharFilter(org.apache.lucene.analysis.charfilter.NormalizeCharMap@3ef95503,
>  java.io.StringReader@70dde633)
>[junit4]   2>   
> org.apache.lucene.analysis.fa.PersianCharFilter(org.apache.lucene.analysis.charfilter.MappingCharFilter@12423b20)
>[junit4]   2> tokenizer=
>[junit4]   2>   org.apache.lucene.analysis.th.ThaiTokenizer()
>[junit4]   2> filters=
>[junit4]   2>   
> org.apache.lucene.analysis.compound.HyphenationCompoundWordTokenFilter(ValidatingTokenFilter@7914bba7
>  
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1,
>  org.apache.lucene.analysis.compound.hyphenation.HyphenationTree@abd7bca)
>[junit4]   2>   
> Conditional:org.apache.lucene.analysis.MockGraphTokenFilter(java.util.Random@56348091,
>  OneTimeWrapper@aa1c073 
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1)
>[junit4]   2>   
> Conditional:org.apache.lucene.analysis.shingle.FixedShingleFilter(OneTimeWrapper@4cf58fce
>  
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1,
>  4, , )
>[junit4]   2>   
> org.apache.lucene.analysis.pt.PortugueseLightStemFilter(ValidatingTokenFilter@3a915324
>  
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1,keyword=false)
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRandomChains 
> -Dtests.method=testRandomChainsWithLargeStrings -Dtests.seed=92344C536D4E00F4 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=en-ZW 
> -Dtests.timezone=Atlantic/Faroe -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR   0.46s J2 | 
> TestRandomChains.testRandomChainsWithLargeStrings <<<
>[junit4]> Throwable #1: java.lang.IllegalStateException: stage 3: 
> inconsistent startOffset at pos=0: 0 vs 5; token=effort
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([92344C536D4E00F4:F86FF34234002007]:0)
>[junit4]>  at 
> org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:109)
>[junit4]>  at 
> org.apache.lucene.analysis.pt.PortugueseLightStemFilter.incrementToken(PortugueseLightStemFilter.java:48)
>[junit4]>  at 
> org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:68)
>[junit4]>  at 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException(BaseTokenStreamTestCase.java:441)
>[junit4]>  at 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:546)
>[junit4]>  at 
> org.apache.lucene.analysis.core.TestRandomChains.testRandomChainsWithLargeStrings(TestRandomChains.java:897)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.re

[jira] [Commented] (LUCENE-8517) TestRandomChains.testRandomChainsWithLargeStrings failure

[ASF subversion and git services (JIRA)]

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

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

Commit 54907903e8d1a5da0c65328f24a1018c5e393afc in lucene-solr's branch 
refs/heads/master from Michael Sokolov
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5490790 ]

LUCENE-8517: do not wrap FixedShingleFilter with conditional in TestRandomChains


> TestRandomChains.testRandomChainsWithLargeStrings failure
> -
>
> Key: LUCENE-8517
> URL: https://issues.apache.org/jira/browse/LUCENE-8517
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Reporter: Steve Rowe
>Priority: Major
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> From 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2828/consoleText], 
> reproduces for me on Java8:
> {noformat}
> Checking out Revision 216f10026b86627750e133fe24ce6a750c470695 
> (refs/remotes/origin/branch_7x)
> [...]
> [java-info] java version "10.0.1"
> [java-info] OpenJDK Runtime Environment (10.0.1+10, Oracle Corporation)
> [java-info] OpenJDK 64-Bit Server VM (10.0.1+10, Oracle Corporation)
> [java-info] Test args: [-XX:-UseCompressedOops -XX:+UseConcMarkSweepGC]
> [...]
>[junit4] Suite: org.apache.lucene.analysis.core.TestRandomChains
>[junit4]   2> Exception from random analyzer: 
>[junit4]   2> charfilters=
>[junit4]   2>   
> org.apache.lucene.analysis.charfilter.MappingCharFilter(org.apache.lucene.analysis.charfilter.NormalizeCharMap@3ef95503,
>  java.io.StringReader@70dde633)
>[junit4]   2>   
> org.apache.lucene.analysis.fa.PersianCharFilter(org.apache.lucene.analysis.charfilter.MappingCharFilter@12423b20)
>[junit4]   2> tokenizer=
>[junit4]   2>   org.apache.lucene.analysis.th.ThaiTokenizer()
>[junit4]   2> filters=
>[junit4]   2>   
> org.apache.lucene.analysis.compound.HyphenationCompoundWordTokenFilter(ValidatingTokenFilter@7914bba7
>  
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1,
>  org.apache.lucene.analysis.compound.hyphenation.HyphenationTree@abd7bca)
>[junit4]   2>   
> Conditional:org.apache.lucene.analysis.MockGraphTokenFilter(java.util.Random@56348091,
>  OneTimeWrapper@aa1c073 
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1)
>[junit4]   2>   
> Conditional:org.apache.lucene.analysis.shingle.FixedShingleFilter(OneTimeWrapper@4cf58fce
>  
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1,
>  4, , )
>[junit4]   2>   
> org.apache.lucene.analysis.pt.PortugueseLightStemFilter(ValidatingTokenFilter@3a915324
>  
> term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1,keyword=false)
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRandomChains 
> -Dtests.method=testRandomChainsWithLargeStrings -Dtests.seed=92344C536D4E00F4 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=en-ZW 
> -Dtests.timezone=Atlantic/Faroe -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] ERROR   0.46s J2 | 
> TestRandomChains.testRandomChainsWithLargeStrings <<<
>[junit4]> Throwable #1: java.lang.IllegalStateException: stage 3: 
> inconsistent startOffset at pos=0: 0 vs 5; token=effort
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([92344C536D4E00F4:F86FF34234002007]:0)
>[junit4]>  at 
> org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:109)
>[junit4]>  at 
> org.apache.lucene.analysis.pt.PortugueseLightStemFilter.incrementToken(PortugueseLightStemFilter.java:48)
>[junit4]>  at 
> org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:68)
>[junit4]>  at 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException(BaseTokenStreamTestCase.java:441)
>[junit4]>  at 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:546)
>[junit4]>  at 
> org.apache.lucene.analysis.core.TestRandomChains.testRandomChainsWithLargeStrings(TestRandomChains.java:897)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.refle

[jira] [Commented] (SOLR-7414) CSVResponseWriter returns empty field when fl alias is combined with '*' selector

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-7414:


 Thanks for the patch. Now I see the reason of introducing 
{{getExplicitRequestedFieldNames}}, but there are two points here:
 * I need one commiter to approve this API extension
 * personally I prefer never return null collections, sure there are plenty of 
this there already, here I need other committer advice as well. 

> CSVResponseWriter returns empty field when fl alias is combined with '*' 
> selector
> -
>
> Key: SOLR-7414
> URL: https://issues.apache.org/jira/browse/SOLR-7414
> Project: Solr
>  Issue Type: Bug
>  Components: Response Writers
>Reporter: Michael Lawrence
>Priority: Major
> Attachments: SOLR-7414-old.patch, SOLR-7414.patch, SOLR-7414.patch
>
>
> Attempting to retrieve all fields while renaming one, e.g., "inStock" to 
> "stocked" (URL below), results in CSV output that has a column for "inStock" 
> (should be "stocked"), and the column has no values. 
> steps to reproduce using 5.1...
> {noformat}
> $ bin/solr -e techproducts
> ...
> $ curl -X POST -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/techproducts/update?commit=true' --data-binary 
> '[{ "id" : "aaa", "bar_i" : 7, "inStock" : true }, { "id" : "bbb", "bar_i" : 
> 7, "inStock" : false }, { "id" : "ccc", "bar_i" : 7, "inStock" : true }]'
> {"responseHeader":{"status":0,"QTime":730}}
> $ curl 
> 'http://localhost:8983/solr/techproducts/query?q=bar_i:7&fl=id,stocked:inStock&wt=csv'
> id,stocked
> aaa,true
> bbb,false
> ccc,true
> $ curl 
> 'http://localhost:8983/solr/techproducts/query?q=bar_i:7&fl=*,stocked:inStock&wt=csv'
> bar_i,id,_version_,inStock
> 7,aaa,1498719888088236032,
> 7,bbb,1498719888090333184,
> 7,ccc,1498719888090333185,
> $ curl 
> 'http://localhost:8983/solr/techproducts/query?q=bar_i:7&fl=stocked:inStock,*&wt=csv'
> bar_i,id,_version_,inStock
> 7,aaa,1498719888088236032,
> 7,bbb,1498719888090333184,
> 7,ccc,1498719888090333185,
> {noformat}



--
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: Poll: Merge jira/http2 to master branch

[Uwe Schindler]

Hi,

Because if you install Jetty, to renable conscrypt, you have to start a special 
command and accept the non-eclipse license:
https://www.eclipse.org/jetty/documentation/9.4.x/jetty-ssl-distribution.html#jetty-conscrypt-distribution

Conscrypt SSL Configuration
Enabling Conscrypt SSL is just as easy as default SSL - enable both the 
conscrypt and ssl modules:

$ cd ${JETTY_HOME}
$ java -jar ../start.jar --add-to-start=ssl,conscrypt

ALERT: There are enabled module(s) with licenses.
The following 1 module(s):
 + contains software not provided by the Eclipse Foundation!
 + contains software not covered by the Eclipse Public License!
 + has not been audited for compliance with its license

 Module: conscrypt
  + Conscrypt is distributed under the Apache Licence 2.0
  + https://github.com/google/conscrypt/blob/master/LICENSE

Proceed (y/N)? y
INFO  : server  transitively enabled, ini template available with 
--add-to-start=server
INFO  : conscrypt   initialized in ${jetty.base}/start.d/conscrypt.ini
INFO  : ssl initialized in ${jetty.base}/start.d/ssl.ini
MKDIR : ${jetty.base}/lib/conscrypt
DOWNLD: 
https://repo1.maven.org/maven2/org/conscrypt/conscrypt-openjdk-uber/1.0.0.RC11/conscrypt-openjdk-uber-1.0.0.RC11.jar
 to ${jetty.base}/lib/conscrypt/conscrypt-uber-1.0.0.RC11.jar
MKDIR : ${jetty.base}/etc
COPY  : ${jetty.home}/modules/conscrypt/conscrypt.xml to 
${jetty.base}/etc/conscrypt.xml
COPY  : ${jetty.home}/modules/ssl/keystore to ${jetty.base}/etc/keystore
INFO  : Base directory was modified
No additional Conscrypt configuration is needed. SSL-specific parameters, like 
keyStorePath and keyStorePassword can still configured as in the example above, 
making use of the ${JETTY_BASE}/start.d/ssl.ini file.

Maybe we should do the same for solr: If you want full performance you may 
install conscrypt in your Solr working dir or the SolrJ client, but otherwise 
it should use non-native code shipped with JDK only. Maybe we should disable 
HTTP2 for Java 8 by default and only enable it if user installs conscrypt.

I have the feeling, we have to include ASF Legal department!
Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Uwe Schindler 
> Sent: Tuesday, November 27, 2018 11:32 AM
> To: dev@lucene.apache.org
> Subject: RE: Poll: Merge jira/http2 to master branch
> 
> Thanks Upayavira,
> 
> I leave that open to Dat to update it. BTW, there are still checksum files
> missing for many jars.
> 
> I'd like to bring one thing into attention: This library conscrypt is ASF2-
> licensed, but the JAR files contain binary versions of an OpenSSL fork named
> BoringSSL. I'd recommend to check the licensing, because OpenSSL licenses
> are a bit strange (some BSD fork, also ASF2, but some code is still outdated 
> - I
> am not sure what the fork actually uses). I have the feeling we should include
> ASF legal department.
> 
> Nevertheless, I am not 100% sure if conscrypt should really be inclued by
> default in SolrJ. As SolrJ is a client library for Solr and can be used by 
> external
> projects, there is the problem of incompatibilities with the native C code
> included. E.g., if one uses SolrJ with IBM J9 or other Java versions different
> from openjdk. So I'd be careful. My question is: Do we really need that
> library. To me it looks like it improves speed only, or is there something 
> that
> requires its use?
> 
> Uwe
> 
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> > -Original Message-
> > From: Malcolm Upayavira Holmes 
> > Sent: Tuesday, November 27, 2018 11:17 AM
> > To: dev@lucene.apache.org
> > Subject: Re: Poll: Merge jira/http2 to master branch
> >
> > Uwe - there is already a release newer than the commit
> >
> > On Tue, 27 Nov 2018, at 8:03 AM, Uwe Schindler wrote:
> > > Ah I figured out, there is an issue open already:
> > > https://github.com/google/conscrypt/issues/560
> > >
> > > Seems to be closed, so we have to wait for a new release, right?
> > >
> > > Uwe
> > >
> > > -
> > > Uwe Schindler
> > > Achterdiek 19, D-28357 Bremen
> > > http://www.thetaphi.de
> > > eMail: u...@thetaphi.de
> > >
> > > > -Original Message-
> > > > From: Uwe Schindler 
> > > > Sent: Tuesday, November 27, 2018 8:48 AM
> > > > To: dev@lucene.apache.org
> > > > Subject: RE: Poll: Merge jira/http2 to master branch
> > > >
> > > > It seems to work with Java 9/10/11, but with Java 8 almost all Solr 
> > > > tests
> > fail.
> > > > Reason is a mising JAR library: conscrypt.jar (which seems to be used by
> > Jetty
> > > > to support some HTTP/2 requires stuff not included in the JDK).
> > > >
> > > > We should at least disable HTTP/2 in Java 8 or add this library (seems 
> > > > to
> > > > contain native code): https://github.com/google/conscrypt#uber-jar
> > > >
> > > > Uwe
> > > >
> > > > -
> > > > Uwe Schindler
> > > > Achterdiek 1

RE: Poll: Merge jira/http2 to master branch

[Uwe Schindler]

Thanks Upayavira,

I leave that open to Dat to update it. BTW, there are still checksum files 
missing for many jars.

I'd like to bring one thing into attention: This library conscrypt is 
ASF2-licensed, but the JAR files contain binary versions of an OpenSSL fork 
named BoringSSL. I'd recommend to check the licensing, because OpenSSL licenses 
are a bit strange (some BSD fork, also ASF2, but some code is still outdated - 
I am not sure what the fork actually uses). I have the feeling we should 
include ASF legal department.

Nevertheless, I am not 100% sure if conscrypt should really be inclued by 
default in SolrJ. As SolrJ is a client library for Solr and can be used by 
external projects, there is the problem of incompatibilities with the native C 
code included. E.g., if one uses SolrJ with IBM J9 or other Java versions 
different from openjdk. So I'd be careful. My question is: Do we really need 
that library. To me it looks like it improves speed only, or is there something 
that requires its use?

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Malcolm Upayavira Holmes 
> Sent: Tuesday, November 27, 2018 11:17 AM
> To: dev@lucene.apache.org
> Subject: Re: Poll: Merge jira/http2 to master branch
> 
> Uwe - there is already a release newer than the commit
> 
> On Tue, 27 Nov 2018, at 8:03 AM, Uwe Schindler wrote:
> > Ah I figured out, there is an issue open already:
> > https://github.com/google/conscrypt/issues/560
> >
> > Seems to be closed, so we have to wait for a new release, right?
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> > > -Original Message-
> > > From: Uwe Schindler 
> > > Sent: Tuesday, November 27, 2018 8:48 AM
> > > To: dev@lucene.apache.org
> > > Subject: RE: Poll: Merge jira/http2 to master branch
> > >
> > > It seems to work with Java 9/10/11, but with Java 8 almost all Solr tests
> fail.
> > > Reason is a mising JAR library: conscrypt.jar (which seems to be used by
> Jetty
> > > to support some HTTP/2 requires stuff not included in the JDK).
> > >
> > > We should at least disable HTTP/2 in Java 8 or add this library (seems to
> > > contain native code): https://github.com/google/conscrypt#uber-jar
> > >
> > > Uwe
> > >
> > > -
> > > Uwe Schindler
> > > Achterdiek 19, D-28357 Bremen
> > > http://www.thetaphi.de
> > > eMail: u...@thetaphi.de
> > >
> > > > -Original Message-
> > > > From: Uwe Schindler 
> > > > Sent: Tuesday, November 27, 2018 12:38 AM
> > > > To: dev@lucene.apache.org
> > > > Subject: RE: Poll: Merge jira/http2 to master branch
> > > >
> > > > OK,
> > > >
> > > > I created 4 Jobs on Policeman Jenkins (Linux, Windows, macos, Solaris).
> On
> > > > ASF Jenkins I created the standard "tests" job for now, others can be
> added
> > > > later. They are called "http2" at the place of the version (instead of
> "7.x",
> > > > "7.6", "master").
> > > >
> > > > Let's see how it behaves,
> > > > Uwe
> > > >
> > > > -
> > > > Uwe Schindler
> > > > Achterdiek 19, D-28357 Bremen
> > > > http://www.thetaphi.de
> > > > eMail: u...@thetaphi.de
> > > >
> > > > > -Original Message-
> > > > > From: Uwe Schindler 
> > > > > Sent: Tuesday, November 27, 2018 12:22 AM
> > > > > To: dev@lucene.apache.org
> > > > > Subject: RE: Poll: Merge jira/http2 to master branch
> > > > >
> > > > > Ah sorry, I did not see the ping. Where did you try to contact me?
> > > > >
> > > > > Uwe
> > > > >
> > > > > -
> > > > > Uwe Schindler
> > > > > Achterdiek 19, D-28357 Bremen
> > > > > http://www.thetaphi.de
> > > > > eMail: u...@thetaphi.de
> > > > >
> > > > > > -Original Message-
> > > > > > From: Chris Hostetter 
> > > > > > Sent: Monday, November 26, 2018 10:59 PM
> > > > > > To: dev@lucene.apache.org
> > > > > > Subject: RE: Poll: Merge jira/http2 to master branch
> > > > > >
> > > > > >
> > > > > > : The job would use the usual randomization anyways, so what's
> your
> > > > > > : special request? So we should see an improvement asap.
> > > > > >
> > > > > > No special request beyond asking you to setup a job on your
> personal
> > > > > > jenkins server -- just pointing out that i tried asking you for 
> > > > > > this via
> > > > > > jira ping 2 weeks ago :)
> > > > > >
> > > > > > And yes: if my experimentation is correct, we should see a much
> lower
> > > > rate
> > > > > > of failures from your box when testing Dat's http2 branch with
> java>9 vs
> > > > > > what we see w/master & 7x
> > > > > >
> > > > > > : > : I’d prefer to just add jenkins jobs for the “http2” branch 
> > > > > > and not
> yet
> > > > > > : >
> > > > > > : > Uwe: note that in particular it would be really helpful to have 
> > > > > > a
> > > > > > : > jira/http2 jenkins job setup on your policeman's jenkins box,
> where
> > > > > java11
> > > > > > : > and java12 are randomized, since you seem to h

Re: Poll: Merge jira/http2 to master branch

[Đạt Cao Mạnh]

Hi Uwe,

It seems that is conflict between settings default security provider of
conscrypt and httpclient. I will try to resolve that problem today.

Thanks!

On Tue, Nov 27, 2018 at 9:11 AM Simon Willnauer 
wrote:

> folks,
>
> I just want to ask if this is an issue or not but this branch is
> associated with a blocker issue for 8.0. If it doesn't have an owner
> or is actively worked on do we still consider it a blocker? I mean
> don't get me wrong but if this is something that we don't dedicate
> time and committer to I think we should re-think the decision if this
> is a blocker or not?
>
> simon
>
> On Tue, Nov 27, 2018 at 9:03 AM Uwe Schindler  wrote:
> >
> > Ah I figured out, there is an issue open already:
> > https://github.com/google/conscrypt/issues/560
> >
> > Seems to be closed, so we have to wait for a new release, right?
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> > > -Original Message-
> > > From: Uwe Schindler 
> > > Sent: Tuesday, November 27, 2018 8:48 AM
> > > To: dev@lucene.apache.org
> > > Subject: RE: Poll: Merge jira/http2 to master branch
> > >
> > > It seems to work with Java 9/10/11, but with Java 8 almost all Solr
> tests fail.
> > > Reason is a mising JAR library: conscrypt.jar (which seems to be used
> by Jetty
> > > to support some HTTP/2 requires stuff not included in the JDK).
> > >
> > > We should at least disable HTTP/2 in Java 8 or add this library (seems
> to
> > > contain native code): https://github.com/google/conscrypt#uber-jar
> > >
> > > Uwe
> > >
> > > -
> > > Uwe Schindler
> > > Achterdiek 19, D-28357 Bremen
> > > http://www.thetaphi.de
> > > eMail: u...@thetaphi.de
> > >
> > > > -Original Message-
> > > > From: Uwe Schindler 
> > > > Sent: Tuesday, November 27, 2018 12:38 AM
> > > > To: dev@lucene.apache.org
> > > > Subject: RE: Poll: Merge jira/http2 to master branch
> > > >
> > > > OK,
> > > >
> > > > I created 4 Jobs on Policeman Jenkins (Linux, Windows, macos,
> Solaris). On
> > > > ASF Jenkins I created the standard "tests" job for now, others can
> be added
> > > > later. They are called "http2" at the place of the version (instead
> of "7.x",
> > > > "7.6", "master").
> > > >
> > > > Let's see how it behaves,
> > > > Uwe
> > > >
> > > > -
> > > > Uwe Schindler
> > > > Achterdiek 19, D-28357 Bremen
> > > > http://www.thetaphi.de
> > > > eMail: u...@thetaphi.de
> > > >
> > > > > -Original Message-
> > > > > From: Uwe Schindler 
> > > > > Sent: Tuesday, November 27, 2018 12:22 AM
> > > > > To: dev@lucene.apache.org
> > > > > Subject: RE: Poll: Merge jira/http2 to master branch
> > > > >
> > > > > Ah sorry, I did not see the ping. Where did you try to contact me?
> > > > >
> > > > > Uwe
> > > > >
> > > > > -
> > > > > Uwe Schindler
> > > > > Achterdiek 19, D-28357 Bremen
> > > > > http://www.thetaphi.de
> > > > > eMail: u...@thetaphi.de
> > > > >
> > > > > > -Original Message-
> > > > > > From: Chris Hostetter 
> > > > > > Sent: Monday, November 26, 2018 10:59 PM
> > > > > > To: dev@lucene.apache.org
> > > > > > Subject: RE: Poll: Merge jira/http2 to master branch
> > > > > >
> > > > > >
> > > > > > : The job would use the usual randomization anyways, so what's
> your
> > > > > > : special request? So we should see an improvement asap.
> > > > > >
> > > > > > No special request beyond asking you to setup a job on your
> personal
> > > > > > jenkins server -- just pointing out that i tried asking you for
> this via
> > > > > > jira ping 2 weeks ago :)
> > > > > >
> > > > > > And yes: if my experimentation is correct, we should see a much
> lower
> > > > rate
> > > > > > of failures from your box when testing Dat's http2 branch with
> java>9 vs
> > > > > > what we see w/master & 7x
> > > > > >
> > > > > > : > : I’d prefer to just add jenkins jobs for the “http2” branch
> and not yet
> > > > > > : >
> > > > > > : > Uwe: note that in particular it would be really helpful to
> have a
> > > > > > : > jira/http2 jenkins job setup on your policeman's jenkins
> box, where
> > > > > java11
> > > > > > : > and java12 are randomized, since you seem to hit the java>9
> SSL
> > > > related
> > > > > > : > bugs the most, and AFAICT those problems are fixed on the
> > > jira/http2
> > > > > > : > branch -- see comments in SOLR-12990 (and related SOLR-12988)
> > > > > >
> > > > > >
> > > > > > -Hoss
> > > > > > http://www.lucidworks.com/
> > > > >
> > > > >
> > > > >
> -
> > > > > 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
> > >
> > >
> > > -

Re: Poll: Merge jira/http2 to master branch

[Malcolm Upayavira Holmes]

Uwe - there is already a release newer than the commit

On Tue, 27 Nov 2018, at 8:03 AM, Uwe Schindler wrote:
> Ah I figured out, there is an issue open already:
> https://github.com/google/conscrypt/issues/560
> 
> Seems to be closed, so we have to wait for a new release, right? 
> 
> Uwe
> 
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> > -Original Message-
> > From: Uwe Schindler 
> > Sent: Tuesday, November 27, 2018 8:48 AM
> > To: dev@lucene.apache.org
> > Subject: RE: Poll: Merge jira/http2 to master branch
> > 
> > It seems to work with Java 9/10/11, but with Java 8 almost all Solr tests 
> > fail.
> > Reason is a mising JAR library: conscrypt.jar (which seems to be used by 
> > Jetty
> > to support some HTTP/2 requires stuff not included in the JDK).
> > 
> > We should at least disable HTTP/2 in Java 8 or add this library (seems to
> > contain native code): https://github.com/google/conscrypt#uber-jar
> > 
> > Uwe
> > 
> > -
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> > 
> > > -Original Message-
> > > From: Uwe Schindler 
> > > Sent: Tuesday, November 27, 2018 12:38 AM
> > > To: dev@lucene.apache.org
> > > Subject: RE: Poll: Merge jira/http2 to master branch
> > >
> > > OK,
> > >
> > > I created 4 Jobs on Policeman Jenkins (Linux, Windows, macos, Solaris). On
> > > ASF Jenkins I created the standard "tests" job for now, others can be 
> > > added
> > > later. They are called "http2" at the place of the version (instead of 
> > > "7.x",
> > > "7.6", "master").
> > >
> > > Let's see how it behaves,
> > > Uwe
> > >
> > > -
> > > Uwe Schindler
> > > Achterdiek 19, D-28357 Bremen
> > > http://www.thetaphi.de
> > > eMail: u...@thetaphi.de
> > >
> > > > -Original Message-
> > > > From: Uwe Schindler 
> > > > Sent: Tuesday, November 27, 2018 12:22 AM
> > > > To: dev@lucene.apache.org
> > > > Subject: RE: Poll: Merge jira/http2 to master branch
> > > >
> > > > Ah sorry, I did not see the ping. Where did you try to contact me?
> > > >
> > > > Uwe
> > > >
> > > > -
> > > > Uwe Schindler
> > > > Achterdiek 19, D-28357 Bremen
> > > > http://www.thetaphi.de
> > > > eMail: u...@thetaphi.de
> > > >
> > > > > -Original Message-
> > > > > From: Chris Hostetter 
> > > > > Sent: Monday, November 26, 2018 10:59 PM
> > > > > To: dev@lucene.apache.org
> > > > > Subject: RE: Poll: Merge jira/http2 to master branch
> > > > >
> > > > >
> > > > > : The job would use the usual randomization anyways, so what's your
> > > > > : special request? So we should see an improvement asap.
> > > > >
> > > > > No special request beyond asking you to setup a job on your personal
> > > > > jenkins server -- just pointing out that i tried asking you for this 
> > > > > via
> > > > > jira ping 2 weeks ago :)
> > > > >
> > > > > And yes: if my experimentation is correct, we should see a much lower
> > > rate
> > > > > of failures from your box when testing Dat's http2 branch with java>9 
> > > > > vs
> > > > > what we see w/master & 7x
> > > > >
> > > > > : > : I’d prefer to just add jenkins jobs for the “http2” branch and 
> > > > > not yet
> > > > > : >
> > > > > : > Uwe: note that in particular it would be really helpful to have a
> > > > > : > jira/http2 jenkins job setup on your policeman's jenkins box, 
> > > > > where
> > > > java11
> > > > > : > and java12 are randomized, since you seem to hit the java>9 SSL
> > > related
> > > > > : > bugs the most, and AFAICT those problems are fixed on the
> > jira/http2
> > > > > : > branch -- see comments in SOLR-12990 (and related SOLR-12988)
> > > > >
> > > > >
> > > > > -Hoss
> > > > > http://www.lucidworks.com/
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

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

[jira] [Commented] (SOLR-12775) Add a deprecated implementation of LowerCaseTokenizer

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12775:


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

SOLR-12775: Add deprecated versions of LowerCaseTokenizer and 
LowerCaseTokenizerFactory


> Add a deprecated implementation of LowerCaseTokenizer
> -
>
> Key: SOLR-12775
> URL: https://issues.apache.org/jira/browse/SOLR-12775
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Blocker
> Fix For: master (8.0)
>
> Attachments: SOLR-12775.patch, SOLR-12775.patch, SOLR-12775.patch, 
> SOLR-12775.patch, SOLR-12775.patch
>
>
> LUCENE-8498 will remove LowerCaseTokenizer and LowerCaseTokenizerFactory from 
> lucene 8.  To make upgrading from Solr 7.x to Solr 8 easier for users who 
> have schemas that use LowerCaseTokenizerFactory, we should add a deprecated 
> copy of the code to the {{org.apache.solr.analysis}} package.



--
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-8562) Speed up merging segments of points with data dimensions

[ASF subversion and git services (JIRA)]

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

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

Commit 72ca4488d1313ffd2b9b8cf43027f7677022e80f in lucene-solr's branch 
refs/heads/jira/http2 from iverase
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=72ca448 ]

LUCENE-8562: Speed up merging segments of points with data dimensions by only 
sorting on the indexed dimensions


> Speed up merging segments of points with data dimensions
> 
>
> Key: LUCENE-8562
> URL: https://issues.apache.org/jira/browse/LUCENE-8562
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Affects Versions: master (8.0), 7.7
>Reporter: Ignacio Vera
>Assignee: Ignacio Vera
>Priority: Major
> Fix For: master (8.0), 7.7
>
> Attachments: LUCENE-8562.patch, LUCENE-8562.patch, LUCENE-8562.patch, 
> LUCENE-8562.patch, LUCENE-8562.patch, LUCENE-8562.patch, LUCENE-8562.patch
>
>
> Currently when merging segments of points with data dimensions, all 
> dimensions are sorted and carried over down the tree even though only 
> indexing dimensions are needed to build the BKD tree. This is needed so leaf 
> node data can be compressed by common prefix.
> But when using _MutablePointValues_, this ordering is done at the leaf level 
> so we can se a similar approach from data dimensions and delay the sorting at 
> leaf level. This seems to speed up indexing time as well as reduce the 
> storage needed for building the index.
>  
>  
>  



--
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-9856) Collect metrics for shard replication and tlog replay on replicas

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-9856:
---

Commit 67cdd21996f716ffb137bbcb8f826794a2632be7 in lucene-solr's branch 
refs/heads/jira/http2 from Andrzej Bialecki
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=67cdd21 ]

SOLR-9856: Update the Ref Guide to no longer list this issue as unresolved.


> Collect metrics for shard replication and tlog replay on replicas
> -
>
> Key: SOLR-9856
> URL: https://issues.apache.org/jira/browse/SOLR-9856
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.0
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Minor
> Fix For: 6.4, 7.0
>
> Attachments: SOLR-9856.patch
>
>
> Using API from SOLR-4735 add metrics for tracking outgoing replication from 
> leader to shard replicas, and for tracking transaction log processing on 
> replicas.



--
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-5211) updating parent as childless makes old children orphans

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-5211:
---

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

SOLR-5211:  Always populate _root_ (if defined).
And, small refactor: Clarified how _version_ is transferred from root to 
children.


> updating parent as childless makes old children orphans
> ---
>
> Key: SOLR-5211
> URL: https://issues.apache.org/jira/browse/SOLR-5211
> Project: Solr
>  Issue Type: Sub-task
>  Components: update
>Affects Versions: 4.5, 6.0
>Reporter: Mikhail Khludnev
>Assignee: David Smiley
>Priority: Blocker
> Fix For: master (8.0)
>
> Attachments: SOLR-5211.patch, SOLR-5211.patch, SOLR-5211.patch, 
> SOLR-5211.patch, SOLR-5211.patch
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> if I have parent with children in the index, I can send update omitting 
> children. as a result old children become orphaned. 
> I suppose separate \_root_ fields makes much trouble. I propose to extend 
> notion of uniqueKey, and let it spans across blocks that makes updates 
> unambiguous.  
> WDYT? Do you like to see a test proves this issue?



--
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-12546) CSVResponseWriter doesnt return non-stored field even when docValues is enabled, when no explicit fl specified

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12546:


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

SOLR-12546: Let csv response writer to handle docValues fields by default.


> CSVResponseWriter doesnt return non-stored field even when docValues is 
> enabled, when no explicit fl specified
> --
>
> Key: SOLR-12546
> URL: https://issues.apache.org/jira/browse/SOLR-12546
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Affects Versions: 7.2.1
>Reporter: Karthik S
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: master (8.0), 7.7
>
> Attachments: SOLR-12546-old.patch, SOLR-12546.patch, 
> SOLR-12546.patch, SOLR-12546.patch
>
>
> As part of this Jira SOLR-2970,  CSVResponseWriter doesn't return fields 
> whose stored attribute set to false, but doesnt consider docvalues.
>  
> Causing fields whose stored=false and docValues =true are not returned when 
> no explicit fl are specified. Behavior must be same as of json/xml response 
> writer..
>  
> Eg:
> -  Created collection with below fields
>  type="string"/> 
>  type="int" stored="false"/>
>  type="plong" stored="false"/>
> 
>  precisionStep="0"/>
> 
>  
>  
> -  Added few documents
> contentid,testint,testlong
> id,1,56
> id2,2,66
>  
> -  http://machine:port/solr/testdocvalue/select?q=*:*&wt=json
> [\{"contentid":"id","_version_":1605281886069850112,
> "timestamp":"2018-07-06T22:28:25.335Z","testint":1,
> "testlong":56},
>   {
> "contentid":"id2","_version_":1605281886075092992,
> "timestamp":"2018-07-06T22:28:25.335Z","testint":2,
> "testlong":66}]
>  
> -  http://machine:port/solr/testdocvalue/select?q=*:*&wt=csv
> "_version_",contentid,timestamp1605281886069850112,id,2018-07-06T22:28:25.335Z1605281886075092992,id2,2018-07-06T22:28:25.335Z
>  
>  



--
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-5211) updating parent as childless makes old children orphans

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-5211:
---

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

SOLR-5211: ignore temporarily pending moshe fixing


> updating parent as childless makes old children orphans
> ---
>
> Key: SOLR-5211
> URL: https://issues.apache.org/jira/browse/SOLR-5211
> Project: Solr
>  Issue Type: Sub-task
>  Components: update
>Affects Versions: 4.5, 6.0
>Reporter: Mikhail Khludnev
>Assignee: David Smiley
>Priority: Blocker
> Fix For: master (8.0)
>
> Attachments: SOLR-5211.patch, SOLR-5211.patch, SOLR-5211.patch, 
> SOLR-5211.patch, SOLR-5211.patch
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> if I have parent with children in the index, I can send update omitting 
> children. as a result old children become orphaned. 
> I suppose separate \_root_ fields makes much trouble. I propose to extend 
> notion of uniqueKey, and let it spans across blocks that makes updates 
> unambiguous.  
> WDYT? Do you like to see a test proves this issue?



--
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-8570) Issue that the synonym filter is not executed in the KOREAN analyzer 'Nori'

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8570: Fix possible NPE in the attribute reflection of the Nori's 
PartOfSpeechAttributeImpl


> Issue that the synonym filter is not executed in the KOREAN analyzer 'Nori'
> ---
>
> Key: LUCENE-8570
> URL: https://issues.apache.org/jira/browse/LUCENE-8570
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: 7.5
>Reporter: YOO JEONGIN
>Priority: Major
> Fix For: 7.6, master (8.0)
>
> Attachments: LUCENE-8570.patch, image-2018-11-21-15-45-57-644.png, 
> image-2018-11-21-15-46-28-114.png, image-2018-11-21-15-46-45-081.png, 
> image-2018-11-22-11-36-09-190.png, image-2018-11-22-11-36-27-916.png
>
>
> 안녕하세요 
>  저는 한국형 형태 분석입니다. 'Nori'를 사용하여 적용 가능한 질문에 답하십시오. 
>  아직까지는 필터가 작동하지 않아 응답이 없습니다. 이 버그는 본래의 기능과 다를 수 있습니다. 
>  "Nori"를 적용 할 수있는 적절한 방법을 선택하십시오. 
>  고맙습니다.
> !image-2018-11-21-15-45-57-644.png!
> !image-2018-11-21-15-46-28-114.png!
> !image-2018-11-21-15-46-45-081.png!
> !image-2018-11-22-11-36-27-916.png!



--
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&focusedCommentId=16700144#comment-16700144
 ] 

ASF subversion and git services commented on SOLR-12740:


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

SOLR-12740: revise migration docs for clarity and typos


> 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

[JENKINS-EA] Lucene-Solr-http2-Linux (64bit/jdk-12-ea+12) - Build # 4 - Still Failing!

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testParallelUpdateQTime

Error Message:
Error from server at 
https://127.0.0.1:33111/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.14.v20181114  
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at https://127.0.0.1:33111/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.14.v20181114




at 
__randomizedtesting.SeedInfo.seed([B6A16E87FB0E83AD:58791516B571563E]: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:196)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testParallelUpdateQTime(CloudSolrClientTest.java:146)
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)

[jira] [Assigned] (LUCENE-8562) Speed up merging segments of points with data dimensions

[Ignacio Vera (JIRA)]

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

Ignacio Vera reassigned LUCENE-8562:


   Resolution: Fixed
 Assignee: Ignacio Vera
Fix Version/s: 7.7
   master (8.0)

> Speed up merging segments of points with data dimensions
> 
>
> Key: LUCENE-8562
> URL: https://issues.apache.org/jira/browse/LUCENE-8562
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Affects Versions: master (8.0), 7.7
>Reporter: Ignacio Vera
>Assignee: Ignacio Vera
>Priority: Major
> Fix For: master (8.0), 7.7
>
> Attachments: LUCENE-8562.patch, LUCENE-8562.patch, LUCENE-8562.patch, 
> LUCENE-8562.patch, LUCENE-8562.patch, LUCENE-8562.patch, LUCENE-8562.patch
>
>
> Currently when merging segments of points with data dimensions, all 
> dimensions are sorted and carried over down the tree even though only 
> indexing dimensions are needed to build the BKD tree. This is needed so leaf 
> node data can be compressed by common prefix.
> But when using _MutablePointValues_, this ordering is done at the leaf level 
> so we can se a similar approach from data dimensions and delay the sorting at 
> leaf level. This seems to speed up indexing time as well as reduce the 
> storage needed for building the index.
>  
>  
>  



--
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-8562) Speed up merging segments of points with data dimensions

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8562: Speed up merging segments of points with data dimensions by only 
sorting on the indexed dimensions


> Speed up merging segments of points with data dimensions
> 
>
> Key: LUCENE-8562
> URL: https://issues.apache.org/jira/browse/LUCENE-8562
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Affects Versions: master (8.0), 7.7
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8562.patch, LUCENE-8562.patch, LUCENE-8562.patch, 
> LUCENE-8562.patch, LUCENE-8562.patch, LUCENE-8562.patch, LUCENE-8562.patch
>
>
> Currently when merging segments of points with data dimensions, all 
> dimensions are sorted and carried over down the tree even though only 
> indexing dimensions are needed to build the BKD tree. This is needed so leaf 
> node data can be compressed by common prefix.
> But when using _MutablePointValues_, this ordering is done at the leaf level 
> so we can se a similar approach from data dimensions and delay the sorting at 
> leaf level. This seems to speed up indexing time as well as reduce the 
> storage needed for building the index.
>  
>  
>  



--
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-8562) Speed up merging segments of points with data dimensions

[ASF subversion and git services (JIRA)]

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

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

Commit 72ca4488d1313ffd2b9b8cf43027f7677022e80f in lucene-solr's branch 
refs/heads/master from iverase
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=72ca448 ]

LUCENE-8562: Speed up merging segments of points with data dimensions by only 
sorting on the indexed dimensions


> Speed up merging segments of points with data dimensions
> 
>
> Key: LUCENE-8562
> URL: https://issues.apache.org/jira/browse/LUCENE-8562
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Affects Versions: master (8.0), 7.7
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8562.patch, LUCENE-8562.patch, LUCENE-8562.patch, 
> LUCENE-8562.patch, LUCENE-8562.patch, LUCENE-8562.patch, LUCENE-8562.patch
>
>
> Currently when merging segments of points with data dimensions, all 
> dimensions are sorted and carried over down the tree even though only 
> indexing dimensions are needed to build the BKD tree. This is needed so leaf 
> node data can be compressed by common prefix.
> But when using _MutablePointValues_, this ordering is done at the leaf level 
> so we can se a similar approach from data dimensions and delay the sorting at 
> leaf level. This seems to speed up indexing time as well as reduce the 
> storage needed for building the index.
>  
>  
>  



--
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: Poll: Merge jira/http2 to master branch

[Simon Willnauer]

folks,

I just want to ask if this is an issue or not but this branch is
associated with a blocker issue for 8.0. If it doesn't have an owner
or is actively worked on do we still consider it a blocker? I mean
don't get me wrong but if this is something that we don't dedicate
time and committer to I think we should re-think the decision if this
is a blocker or not?

simon

On Tue, Nov 27, 2018 at 9:03 AM Uwe Schindler  wrote:
>
> Ah I figured out, there is an issue open already:
> https://github.com/google/conscrypt/issues/560
>
> Seems to be closed, so we have to wait for a new release, right?
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Uwe Schindler 
> > Sent: Tuesday, November 27, 2018 8:48 AM
> > To: dev@lucene.apache.org
> > Subject: RE: Poll: Merge jira/http2 to master branch
> >
> > It seems to work with Java 9/10/11, but with Java 8 almost all Solr tests 
> > fail.
> > Reason is a mising JAR library: conscrypt.jar (which seems to be used by 
> > Jetty
> > to support some HTTP/2 requires stuff not included in the JDK).
> >
> > We should at least disable HTTP/2 in Java 8 or add this library (seems to
> > contain native code): https://github.com/google/conscrypt#uber-jar
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> > > -Original Message-
> > > From: Uwe Schindler 
> > > Sent: Tuesday, November 27, 2018 12:38 AM
> > > To: dev@lucene.apache.org
> > > Subject: RE: Poll: Merge jira/http2 to master branch
> > >
> > > OK,
> > >
> > > I created 4 Jobs on Policeman Jenkins (Linux, Windows, macos, Solaris). On
> > > ASF Jenkins I created the standard "tests" job for now, others can be 
> > > added
> > > later. They are called "http2" at the place of the version (instead of 
> > > "7.x",
> > > "7.6", "master").
> > >
> > > Let's see how it behaves,
> > > Uwe
> > >
> > > -
> > > Uwe Schindler
> > > Achterdiek 19, D-28357 Bremen
> > > http://www.thetaphi.de
> > > eMail: u...@thetaphi.de
> > >
> > > > -Original Message-
> > > > From: Uwe Schindler 
> > > > Sent: Tuesday, November 27, 2018 12:22 AM
> > > > To: dev@lucene.apache.org
> > > > Subject: RE: Poll: Merge jira/http2 to master branch
> > > >
> > > > Ah sorry, I did not see the ping. Where did you try to contact me?
> > > >
> > > > Uwe
> > > >
> > > > -
> > > > Uwe Schindler
> > > > Achterdiek 19, D-28357 Bremen
> > > > http://www.thetaphi.de
> > > > eMail: u...@thetaphi.de
> > > >
> > > > > -Original Message-
> > > > > From: Chris Hostetter 
> > > > > Sent: Monday, November 26, 2018 10:59 PM
> > > > > To: dev@lucene.apache.org
> > > > > Subject: RE: Poll: Merge jira/http2 to master branch
> > > > >
> > > > >
> > > > > : The job would use the usual randomization anyways, so what's your
> > > > > : special request? So we should see an improvement asap.
> > > > >
> > > > > No special request beyond asking you to setup a job on your personal
> > > > > jenkins server -- just pointing out that i tried asking you for this 
> > > > > via
> > > > > jira ping 2 weeks ago :)
> > > > >
> > > > > And yes: if my experimentation is correct, we should see a much lower
> > > rate
> > > > > of failures from your box when testing Dat's http2 branch with java>9 
> > > > > vs
> > > > > what we see w/master & 7x
> > > > >
> > > > > : > : I’d prefer to just add jenkins jobs for the “http2” branch and 
> > > > > not yet
> > > > > : >
> > > > > : > Uwe: note that in particular it would be really helpful to have a
> > > > > : > jira/http2 jenkins job setup on your policeman's jenkins box, 
> > > > > where
> > > > java11
> > > > > : > and java12 are randomized, since you seem to hit the java>9 SSL
> > > related
> > > > > : > bugs the most, and AFAICT those problems are fixed on the
> > jira/http2
> > > > > : > branch -- see comments in SOLR-12990 (and related SOLR-12988)
> > > > >
> > > > >
> > > > > -Hoss
> > > > > http://www.lucidworks.com/
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

---

[jira] [Commented] (LUCENE-8562) Speed up merging segments of points with data dimensions

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8562:
--

+1

> Speed up merging segments of points with data dimensions
> 
>
> Key: LUCENE-8562
> URL: https://issues.apache.org/jira/browse/LUCENE-8562
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Affects Versions: master (8.0), 7.7
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8562.patch, LUCENE-8562.patch, LUCENE-8562.patch, 
> LUCENE-8562.patch, LUCENE-8562.patch, LUCENE-8562.patch, LUCENE-8562.patch
>
>
> Currently when merging segments of points with data dimensions, all 
> dimensions are sorted and carried over down the tree even though only 
> indexing dimensions are needed to build the BKD tree. This is needed so leaf 
> node data can be compressed by common prefix.
> But when using _MutablePointValues_, this ordering is done at the leaf level 
> so we can se a similar approach from data dimensions and delay the sorting at 
> leaf level. This seems to speed up indexing time as well as reduce the 
> storage needed for building the index.
>  
>  
>  



--
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-8562) Speed up merging segments of points with data dimensions

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8562:


| (/) *{color:green}+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 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
29s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m 32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m 32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m 32s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 14m 
24s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 17m 28s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8562 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12949498/LUCENE-8562.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 4.4.0-137-generic #163~14.04.1-Ubuntu SMP Mon 
Sep 24 17:14:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 68c0774 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | 1.8.0_191 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/126/testReport/ |
| modules | C: lucene/core U: lucene/core |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/126/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Speed up merging segments of points with data dimensions
> 
>
> Key: LUCENE-8562
> URL: https://issues.apache.org/jira/browse/LUCENE-8562
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Affects Versions: master (8.0), 7.7
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8562.patch, LUCENE-8562.patch, LUCENE-8562.patch, 
> LUCENE-8562.patch, LUCENE-8562.patch, LUCENE-8562.patch, LUCENE-8562.patch
>
>
> Currently when merging segments of points with data dimensions, all 
> dimensions are sorted and carried over down the tree even though only 
> indexing dimensions are needed to build the BKD tree. This is needed so leaf 
> node data can be compressed by common prefix.
> But when using _MutablePointValues_, this ordering is done at the leaf level 
> so we can se a similar approach from data dimensions and delay the sorting at 
> leaf level. This seems to speed up indexing time as well as reduce the 
> storage needed for building the index.
>  
>  
>  



--
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-SmokeRelease-7.6 - Build # 14 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.6/14/

No tests ran.

Build Log:
[...truncated 23437 lines...]
[asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
 [java] Processed 2443 links (1994 relative) to 3203 anchors in 247 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.6/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.6/solr/package/changes

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.6/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.6/solr/package/solr-7.6.0.tgz
 into 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.6/solr/build/solr.tgz.unpacked

generate-maven-artifacts:

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.6/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.6/lucene/top-level-ivy-settings.xml

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.6/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.6/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.6/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.6/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.6/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.6/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.6/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.6/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.6/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:co

[JENKINS] Lucene-Solr-7.6-Windows (32bit/jdk1.8.0_172) - Build # 10 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.6-Windows/10/
Java: 32bit/jdk1.8.0_172 -client -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimGenericDistributedQueue.testDistributedQueueBlocking

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at 
__randomizedtesting.SeedInfo.seed([ED392C37B9D3420F:A8935E4EFD81FE7B]:0)
at java.util.concurrent.FutureTask.get(FutureTask.java:205)
at 
org.apache.solr.cloud.autoscaling.sim.TestSimDistributedQueue.testDistributedQueueBlocking(TestSimDistributedQueue.java:102)
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:  
junit.framework.TestSuite.org.apache.solr.cloud.autoscaling.sim.TestSimGenericDistributedQueue

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.cloud.autoscaling.sim.TestSimGenericDistributedQueue: 1) 
Thread[id=34796, name=sdqtest--11013-thread-1, state=TIMED_WAITING, 
group=TGR

[jira] [Created] (SOLR-13016) Computing suggestions when policy have "#EQUAL" or "#ALL" rules take too long

[Noble Paul (JIRA)]

Noble Paul created SOLR-13016:
-

 Summary: Computing suggestions when policy have "#EQUAL" or "#ALL" 
rules take too long
 Key: SOLR-13016
 URL: https://issues.apache.org/jira/browse/SOLR-13016
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul


When rules have computed values such as "#EQUAL" or "#ALL" , it takes too long 
to compute. The problem is these values are computed too many times and as the 
no:of nodes increase it almost takes forever. These values don't change and 
they can be cached



--
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: Jenkins test report improvements: Suspicious (Recent) Failure Rates

[Dawid Weiss]

Hi Chris.

bq. if the jenkins build re-runs a TestCase 5 times, there's still
only one section for that suite

I don't know about Jenkins XML, but this behavior is quite all right.
Suite exceptions are either from static class init blocks or from
"outside of test" scopes (like rule initialization, cleanup,
Before/AfterClass hooks, etc.). These are performed once per class,
regardless of how many tests a given class has associated to it. Don't
know if this helps anyhow.

Dawid

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

RE: Poll: Merge jira/http2 to master branch

[Uwe Schindler]

Ah I figured out, there is an issue open already:
https://github.com/google/conscrypt/issues/560

Seems to be closed, so we have to wait for a new release, right? 

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Uwe Schindler 
> Sent: Tuesday, November 27, 2018 8:48 AM
> To: dev@lucene.apache.org
> Subject: RE: Poll: Merge jira/http2 to master branch
> 
> It seems to work with Java 9/10/11, but with Java 8 almost all Solr tests 
> fail.
> Reason is a mising JAR library: conscrypt.jar (which seems to be used by Jetty
> to support some HTTP/2 requires stuff not included in the JDK).
> 
> We should at least disable HTTP/2 in Java 8 or add this library (seems to
> contain native code): https://github.com/google/conscrypt#uber-jar
> 
> Uwe
> 
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> > -Original Message-
> > From: Uwe Schindler 
> > Sent: Tuesday, November 27, 2018 12:38 AM
> > To: dev@lucene.apache.org
> > Subject: RE: Poll: Merge jira/http2 to master branch
> >
> > OK,
> >
> > I created 4 Jobs on Policeman Jenkins (Linux, Windows, macos, Solaris). On
> > ASF Jenkins I created the standard "tests" job for now, others can be added
> > later. They are called "http2" at the place of the version (instead of 
> > "7.x",
> > "7.6", "master").
> >
> > Let's see how it behaves,
> > Uwe
> >
> > -
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> > > -Original Message-
> > > From: Uwe Schindler 
> > > Sent: Tuesday, November 27, 2018 12:22 AM
> > > To: dev@lucene.apache.org
> > > Subject: RE: Poll: Merge jira/http2 to master branch
> > >
> > > Ah sorry, I did not see the ping. Where did you try to contact me?
> > >
> > > Uwe
> > >
> > > -
> > > Uwe Schindler
> > > Achterdiek 19, D-28357 Bremen
> > > http://www.thetaphi.de
> > > eMail: u...@thetaphi.de
> > >
> > > > -Original Message-
> > > > From: Chris Hostetter 
> > > > Sent: Monday, November 26, 2018 10:59 PM
> > > > To: dev@lucene.apache.org
> > > > Subject: RE: Poll: Merge jira/http2 to master branch
> > > >
> > > >
> > > > : The job would use the usual randomization anyways, so what's your
> > > > : special request? So we should see an improvement asap.
> > > >
> > > > No special request beyond asking you to setup a job on your personal
> > > > jenkins server -- just pointing out that i tried asking you for this via
> > > > jira ping 2 weeks ago :)
> > > >
> > > > And yes: if my experimentation is correct, we should see a much lower
> > rate
> > > > of failures from your box when testing Dat's http2 branch with java>9 vs
> > > > what we see w/master & 7x
> > > >
> > > > : > : I’d prefer to just add jenkins jobs for the “http2” branch and 
> > > > not yet
> > > > : >
> > > > : > Uwe: note that in particular it would be really helpful to have a
> > > > : > jira/http2 jenkins job setup on your policeman's jenkins box, where
> > > java11
> > > > : > and java12 are randomized, since you seem to hit the java>9 SSL
> > related
> > > > : > bugs the most, and AFAICT those problems are fixed on the
> jira/http2
> > > > : > branch -- see comments in SOLR-12990 (and related SOLR-12988)
> > > >
> > > >
> > > > -Hoss
> > > > http://www.lucidworks.com/
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


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