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

[Policeman Jenkins Server]

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

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

Error Message:
Fetching cluster properties not supported using the HttpClusterStateProvider. 
ZkClientClusterStateProvider can be used for this.

Stack Trace:
java.lang.UnsupportedOperationException: Fetching cluster properties not 
supported using the HttpClusterStateProvider. ZkClientClusterStateProvider can 
be used for this.
at 
__randomizedtesting.SeedInfo.seed([A61E4C7512D4D1DD:B6630BBCE737D14A]:0)
at 
org.apache.solr.client.solrj.impl.HttpClusterStateProvider.getClusterProperties(HttpClusterStateProvider.java:254)
at 
org.apache.solr.client.solrj.impl.ClusterStateProvider.getClusterProperty(ClusterStateProvider.java:65)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1019)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testHandlingOfStaleAlias(CloudSolrClientTest.java:226)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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)
  

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestNRTOpen

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_ACC843E61AB5FE1D-001\init-core-data-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_ACC843E61AB5FE1D-001\init-core-data-001

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_ACC843E61AB5FE1D-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_ACC843E61AB5FE1D-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_ACC843E61AB5FE1D-001\init-core-data-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_ACC843E61AB5FE1D-001\init-core-data-001
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_ACC843E61AB5FE1D-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestNRTOpen_ACC843E61AB5FE1D-001

at __randomizedtesting.SeedInfo.seed([ACC843E61AB5FE1D]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
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.update.HardAutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([ACC843E61AB5FE1D:161A2C9E999B1008]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:884)
at 
org.apache.solr.update.HardAutoCommitTest.testCommitWithin(HardAutoCommitTest.java:100)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/613/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth: 1) 
Thread[id=25768, name=jetty-launcher-4975-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestImpersonationWithHadoopAuth] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)   
 2) Thread[id=25756, name=jetty-launcher-4975-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestImpersonationWithHadoopAuth] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth: 
   1) Thread[id=25768, name=jetty-launcher-4975-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestImpersonationWithHadoopAuth]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testMaxTime

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([54966A67ECC0F5FB:CE621785725A69C7]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:884)
at 
org.apache.solr.update.AutoCommitTest.testMaxTime(AutoCommitTest.java:293)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=0]
xml response was: 

00500500500500500muLti-Default422017-10-15T01:36:45.625Z158128553918464000542


request was:q=id:500==0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:877)
... 40 more


FAILED:  

[JENKINS] Lucene-Solr-Tests-7.1 - Build # 2 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.1/2/

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.TestTlogReplica

Error Message:
ObjectTracker found 4 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, InternalHttpClient, SolrCore] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:494)  
at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:338) 
 at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:421) 
 at 
org.apache.solr.handler.ReplicationHandler.lambda$setupPolling$12(ReplicationHandler.java:1185)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:92)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:742)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:935)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:844)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1029)
  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:943)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:384)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:389)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:745)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:726)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:507)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:426)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:534)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)  at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) 
 at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
  at 

[JENKINS] Lucene-Solr-7.1-Linux (64bit/jdk-9) - Build # 5 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.1-Linux/5/
Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseSerialGC --illegal-access=deny

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete

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

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


Error 404 


HTTP ERROR: 404
Problem accessing /solr/testcollection_shard1_replica_n3/update. Reason:
Can not find: /solr/testcollection_shard1_replica_n3/update
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.20.v20170531



at 
__randomizedtesting.SeedInfo.seed([8895359E947A3DCB:2B6F9B3B1392D76E]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:539)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete(TestCollectionsAPIViaSolrCloudCluster.java:167)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.cloud.TestAuthenticationFramework.testBasics

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

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


Error 404 


HTTP ERROR: 404
Problem accessing /solr/testcollection_shard1_replica_n2/update. Reason:
Can not find: /solr/testcollection_shard1_replica_n2/update
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.20.v20170531



at 
__randomizedtesting.SeedInfo.seed([10F982A01A7B68B3:2D212C8C229536C3]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:539)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.TestAuthenticationFramework.collectionCreateSearchDeleteTwice(TestAuthenticationFramework.java:126)
at 
org.apache.solr.cloud.TestAuthenticationFramework.testBasics(TestAuthenticationFramework.java:74)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[jira] [Commented] (SOLR-11423) Overseer queue needs a hard cap (maximum size) that clients respect

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-11423:
---

Is it possible to pick a number related to ZK's inherent limits?  That's really 
the goal here, prevent Solr from destroying ZK.

> Overseer queue needs a hard cap (maximum size) that clients respect
> ---
>
> Key: SOLR-11423
> URL: https://issues.apache.org/jira/browse/SOLR-11423
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Scott Blum
>Assignee: Scott Blum
>
> When Solr gets into pathological GC thrashing states, it can fill the 
> overseer queue with literally thousands and thousands of queued state 
> changes.  Many of these end up being duplicated up/down state updates.  Our 
> production cluster has gotten to the 100k queued items level many times, and 
> there's nothing useful you can do at this point except manually purge the 
> queue in ZK.  Recently, it hit 3 million queued items, at which point our 
> entire ZK cluster exploded.
> I propose a hard cap.  Any client trying to enqueue a item when a queue is 
> full would throw an exception.  I was thinking maybe 10,000 items would be a 
> reasonable limit.  Thoughts?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11423) Overseer queue needs a hard cap (maximum size) that clients respect

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-11423:
---

I understand that it's not fool proof. However, when a user has hit a limit and 
he has no way of changing it other than downgrading to an older solr is worse. 
If we are on customer support this is a nightmare

> Overseer queue needs a hard cap (maximum size) that clients respect
> ---
>
> Key: SOLR-11423
> URL: https://issues.apache.org/jira/browse/SOLR-11423
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Scott Blum
>Assignee: Scott Blum
>
> When Solr gets into pathological GC thrashing states, it can fill the 
> overseer queue with literally thousands and thousands of queued state 
> changes.  Many of these end up being duplicated up/down state updates.  Our 
> production cluster has gotten to the 100k queued items level many times, and 
> there's nothing useful you can do at this point except manually purge the 
> queue in ZK.  Recently, it hit 3 million queued items, at which point our 
> entire ZK cluster exploded.
> I propose a hard cap.  Any client trying to enqueue a item when a queue is 
> full would throw an exception.  I was thinking maybe 10,000 items would be a 
> reasonable limit.  Thoughts?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20676/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseSerialGC

2 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Error from server at 
https://127.0.0.1:33505/solr/awhollynewcollection_0_shard1_replica_n1: 
ClusterState says we are the leader 
(https://127.0.0.1:33505/solr/awhollynewcollection_0_shard1_replica_n1), but 
locally we don't think so. Request came from null

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at 
https://127.0.0.1:33505/solr/awhollynewcollection_0_shard1_replica_n1: 
ClusterState says we are the leader 
(https://127.0.0.1:33505/solr/awhollynewcollection_0_shard1_replica_n1), but 
locally we don't think so. Request came from null
at 
__randomizedtesting.SeedInfo.seed([D8A04B96C2792D36:90D53F22C44A02A3]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:539)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:459)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11444:
-

Ugh; looks like I'm wrong about something: While I saw no _explicit_ alias 
recursive resolution, there was in effect one level of this in HttpSolrCall due 
to the second call site of looking up aliases.  I found this via shelving this 
patch's changes while keeping the AliasIntegrationTest changes (including 
specifically your test for alias of an alias) and running it in a debugger and 
seeing it work.  However note while it did work, it didn't work when the 
collection/alias was specified as a parameter -- searchSeveralWays tests many 
ways to refer to the intended collection/alias.  This double-resolution was not 
previously tested -- so who knows wether it was supposed to work this way.  
Perhaps it _was_ intended since the creating of an alias pointing to an alias 
was tested even though it was forgotten to test actually using it.  

Where does this leave us...?  Well... we could add explicit double-resolution 
support and test, but do this with a system property flag? Then we remove in 
8.0; I don't like aliases pointing to aliases.

bq. And on a side note, WDYT about including the bits from SOLR-11488 that 
dis-allows deleting a collection if any alias points to it in this JIRA?

I reviewed that patch and commented there that I liked it.

> Improve Aliases.java and comma delimited collection list handling
> -
>
> Key: SOLR-11444
> URL: https://issues.apache.org/jira/browse/SOLR-11444
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_11444_Aliases.patch, SOLR_11444_Aliases.patch
>
>
> While starting to look at SOLR-11299 I noticed some brittleness in 
> assumptions about Strings that refer to a collection.  Sometimes they are in 
> fact references to comma separated lists, which appears was added with the 
> introduction of collection aliases (an alias can refer to a comma delimited 
> list).  So Java's type system kind of goes out the window when we do this.  
> In one case this leads to a bug -- CloudSolrClient will throw an NPE if you 
> try to write to such an alias.  Sending an update via HTTP will allow it and 
> send it to the first in the list.
> So this issue is about refactoring and some little improvements pertaining to 
> Aliases.java plus certain key spots that deal with collection references.  I 
> don't think I want to go as far as changing the public SolrJ API except to 
> adding documentation on what's possible.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11490) Add @since javadoc tags to the interesting Solr/Lucene classes

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-11490:
--

I started on a - very hacky so far - utility that may do something close to 
required for all classes descending from one root. 

Here is an output for TupleStream and its descendent. These are sorted by 
lowest detected version and then by class name. No inner classes yet, I know 
about 5 inner classes are missing. [~joel.bernstein] could you sanity check 
that these make sense. 

{panel}
CloudSolrStream.java => 5.1.0
MergeStream.java => 5.1.0
ParallelStream.java => 5.1.0
PushBackStream.java => 5.1.0
RankStream.java => 5.1.0
ReducerStream.java => 5.1.0
SolrStream.java => 5.1.0
StreamHandler.java => 5.1.0
TupleStream.java => 5.1.0
UniqueStream.java => 5.1.0
BiJoinStream.java => 6.0.0
ComplementStream.java => 6.0.0
DaemonStream.java => 6.0.0
ExceptionStream.java => 6.0.0
FacetStream.java => 6.0.0
HashJoinStream.java => 6.0.0
InnerJoinStream.java => 6.0.0
IntersectStream.java => 6.0.0
JDBCStream.java => 6.0.0
JoinStream.java => 6.0.0
LeftOuterJoinStream.java => 6.0.0
OuterHashJoinStream.java => 6.0.0
RollupStream.java => 6.0.0
SelectStream.java => 6.0.0
StatsStream.java => 6.0.0
TopicStream.java => 6.0.0
UpdateStream.java => 6.0.0
GatherNodesStream.java => 6.1.0
GraphHandler.java => 6.1.0
RandomStream.java => 6.1.0
ShortestPathStream.java => 6.1.0
SortStream.java => 6.1.0
FeaturesSelectionStream.java => 6.2.0
ScoreNodesStream.java => 6.2.0
TextLogitStream.java => 6.2.0
ClassifyStream.java => 6.3.0
CommitStream.java => 6.3.0
ExecutorStream.java => 6.3.0
FetchStream.java => 6.3.0
ModelStream.java => 6.3.0
HavingStream.java => 6.4.0
NullStream.java => 6.4.0
PriorityStream.java => 6.4.0
SignificantTermsStream.java => 6.5.0
CalculatorStream.java => 6.6.0
CartesianProductStream.java => 6.6.0
CellStream.java => 6.6.0
EchoStream.java => 6.6.0
EvalStream.java => 6.6.0
GetStream.java => 6.6.0
LetStream.java => 6.6.0
ListStream.java => 6.6.0
ShuffleStream.java => 6.6.0
TimeSeriesStream.java => 6.6.0
TupStream.java => 6.6.0
CalciteJDBCStream.java => 7.0.0
KnnStream.java => 7.0.0
SqlStream.java => 7.0.0
{panel}

> Add @since javadoc tags to the interesting Solr/Lucene classes
> --
>
> Key: SOLR-11490
> URL: https://issues.apache.org/jira/browse/SOLR-11490
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
>
> As per the discussion on the dev list, it may be useful to add Javadoc since 
> tags to significant (or even all) Java files.
> For user-facing files (such as analyzers, URPs, stream evaluators, etc) it 
> would be useful when trying to identifying whether a particular class only 
> comes later than user's particular version.
> For other classes, it may be useful for historical reasons.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11490) Add @since javadoc tags to the interesting Solr/Lucene classes

[Alexandre Rafalovitch (JIRA)]

Alexandre Rafalovitch created SOLR-11490:


 Summary: Add @since javadoc tags to the interesting Solr/Lucene 
classes
 Key: SOLR-11490
 URL: https://issues.apache.org/jira/browse/SOLR-11490
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Alexandre Rafalovitch
Assignee: Alexandre Rafalovitch
Priority: Minor


As per the discussion on the dev list, it may be useful to add Javadoc since 
tags to significant (or even all) Java files.

For user-facing files (such as analyzers, URPs, stream evaluators, etc) it 
would be useful when trying to identifying whether a particular class only 
comes later than user's particular version.

For other classes, it may be useful for historical reasons.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1402 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1402/

9 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader

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

Stack Trace:
java.lang.AssertionError: expected:<2> but was:<3>
at 
__randomizedtesting.SeedInfo.seed([174C2DA04E69B19C:F1DB196077EB48FD]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:110)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-11444:
-

This patch fixes a bug I was just puzzling over. While reading code in 
HttpSolrCall, I couldn't figure out how it was possible to find an alias from a 
node not part of that alias... finally I set up a test, and found that in fact 
it did fail...

{code}
{
  "error":{
"metadata":[
  "error-class","org.apache.solr.common.SolrException",
  
"root-error-class","org.apache.zookeeper.KeeperException$SessionExpiredException"],
"msg":"Could not load collection from ZK: test1",
"code":400}}
{code}

That was from a 4 node cluster with collection *test1* aliased as *test1alias* 
that had 1 shard and replication factor 1, which were allocated to nodes on 
port 8981 and 8982, from which all seemed normal, but errors like this occured 
if one tried to use the test1alias name from the node on port 8983 

I was about to file a bug but then I applied this patch since it seemed to be 
in exactly the section of code that didn't make sense, and poof the issue 
disappeared :)

> Improve Aliases.java and comma delimited collection list handling
> -
>
> Key: SOLR-11444
> URL: https://issues.apache.org/jira/browse/SOLR-11444
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_11444_Aliases.patch, SOLR_11444_Aliases.patch
>
>
> While starting to look at SOLR-11299 I noticed some brittleness in 
> assumptions about Strings that refer to a collection.  Sometimes they are in 
> fact references to comma separated lists, which appears was added with the 
> introduction of collection aliases (an alias can refer to a comma delimited 
> list).  So Java's type system kind of goes out the window when we do this.  
> In one case this leads to a bug -- CloudSolrClient will throw an NPE if you 
> try to write to such an alias.  Sending an update via HTTP will allow it and 
> send it to the first in the list.
> So this issue is about refactoring and some little improvements pertaining to 
> Aliases.java plus certain key spots that deal with collection references.  I 
> don't think I want to go as far as changing the public SolrJ API except to 
> adding documentation on what's possible.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11292) Querying against an alias can lead to incorrect routing

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11292:
--

Hi David,

Let me apply SOLR-11444 and see the if it fixes the routing

> Querying against an alias can lead to incorrect routing
> ---
>
> Key: SOLR-11292
> URL: https://issues.apache.org/jira/browse/SOLR-11292
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>
> collection1 has 2 shards and 1 replica
> collection2 has 8 shards and 1 replica
> I have 8 nodes so collection2 is spread across all 8 , while collection1 is 
> hosted by two nodes
> If we create an alias called "collection1" and point it to "collection2".
> Querying against the alias "collection1" works as expected but what I noticed 
> was the top level queries would only hit 2 out of the 8 JVMs when querying 
> using SolrJ
> It turns out that SolrJ is using the state.json of collection1 ( the actual 
> collection ) and routing queries to only those nodes.
> There are two negatives to this:
>  - If those two nodes are down all queries fail.
>  - Top level queries are only routed to those two nodes thus causing a skew 
> in the top level requests
> The obvious solution would be to use the state.json file of the underlying 
> collection that the alias is pointing to  . But if we have the alias pointing 
> to multiple collections then this might get tricky?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11299) Time partitioned collections (umbrella issue)

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11299:
-

bq. the cost of DateFormat.parse() of some number of partition names for every 
doc

Ah, yes.  So it seems we could grab the Aliases instance and if it's the very 
same one as the last instance, then the previous parsing is still valid.  In 
other words, cache the parsing.

> Time partitioned collections (umbrella issue)
> -
>
> Key: SOLR-11299
> URL: https://issues.apache.org/jira/browse/SOLR-11299
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
>
> Solr ought to have the ability to manage large-scale time-series data (think 
> logs or sensor data / IOT) itself without a lot of manual/external work.  The 
> most naive and painless approach today is to create a collection with a high 
> numShards with hash routing but this isn't as good as partitioning the 
> underlying indexes by time for these reasons:
> * Easy to scale up/down horizontally as data/requirements change.  (No need 
> to over-provision, use shard splitting, or re-index with different config)
> * Faster queries: 
> ** can search fewer shards, reducing overall load
> ** realtime search is more tractable (since most shards are stable -- 
> good caches)
> ** "recent" shards (that might be queried more) can be allocated to 
> faster hardware
> ** aged out data is simply removed, not marked as deleted.  Deleted docs 
> still have search overhead.
> * Outages of a shard result in a degraded but sometimes a useful system 
> nonetheless (compare to random subset missing)
> Ideally you could set this up once and then simply work with a collection 
> (potentially actually an alias) in a normal way (search or update), letting 
> Solr handle the addition of new partitions, removing of old ones, and 
> appropriate routing of requests depending on their nature.
> This issue is an umbrella issue for the particular tasks that will make it 
> all happen -- either subtasks or issue linking.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.x-Windows (32bit/jdk1.8.0_144) - Build # 248 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/248/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  
org.apache.solr.cloud.TestCloudSearcherWarming.testRepFactor1LeaderStartup

Error Message:
 null Live Nodes: [127.0.0.1:57038_solr] Last available state: 
DocCollection(testRepFactor1LeaderStartup//collections/testRepFactor1LeaderStartup/state.json/4)={
   "pullReplicas":"0",   "replicationFactor":"1",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   
"replicas":{"core_node2":{   
"core":"testRepFactor1LeaderStartup_shard1_replica_n1",   
"base_url":"http://127.0.0.1:57038/solr;,   
"node_name":"127.0.0.1:57038_solr",   "state":"active",   
"type":"NRT",   "leader":"true",   "router":{"name":"compositeId"}, 
  "maxShardsPerNode":"1",   "autoAddReplicas":"false",   "nrtReplicas":"1",   
"tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: 
null
Live Nodes: [127.0.0.1:57038_solr]
Last available state: 
DocCollection(testRepFactor1LeaderStartup//collections/testRepFactor1LeaderStartup/state.json/4)={
  "pullReplicas":"0",
  "replicationFactor":"1",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{"core_node2":{
  "core":"testRepFactor1LeaderStartup_shard1_replica_n1",
  "base_url":"http://127.0.0.1:57038/solr;,
  "node_name":"127.0.0.1:57038_solr",
  "state":"active",
  "type":"NRT",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "nrtReplicas":"1",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([225115A8932EDC87:F579587082CE9569]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269)
at 
org.apache.solr.cloud.TestCloudSearcherWarming.testRepFactor1LeaderStartup(TestCloudSearcherWarming.java:126)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[jira] [Commented] (SOLR-11285) Support simulations at scale in the autoscaling framework

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11285:


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

SOLR-11285: Support simulations at scale in the autoscaling framework,
part 1 (refactoring).


> Support simulations at scale in the autoscaling framework
> -
>
> Key: SOLR-11285
> URL: https://issues.apache.org/jira/browse/SOLR-11285
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
> Attachments: SOLR-11285.patch
>
>
> This is a spike to investigate how difficult it would be to modify the 
> autoscaling framework so that it's possible to run simulated large-scale 
> experiments and test its dynamic behavior without actually spinning up a 
> large cluster.
> Currently many components rely heavily on actual Solr, ZK and behavior of ZK 
> watches, or insist on making actual HTTP calls. Notable exception is the core 
> Policy framework where most of the ZK / Solr details are abstracted.
> As the algorithms for autoscaling that we implement become more and more 
> complex the ability to effectively run multiple large simulations will be 
> crucial - it's very easy to unknowingly introduce catastrophic instabilities 
> that don't manifest themselves in regular unit tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: 6.6.2 Release

[Erick Erickson]

Thanks! I ran precommit and test after the commit and all's well

On Sat, Oct 14, 2017 at 8:27 AM, Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> No problem, I'll pick up your commit. :-)
>
> On Sat, Oct 14, 2017 at 8:51 PM, Erick Erickson 
> wrote:
>
>> Committed now.
>>
>>
>>
>> On Sat, Oct 14, 2017 at 8:19 AM, Erick Erickson 
>> wrote:
>>
>>> Michael: Good catch. Have I mentioned lately that Git and I don't get
>>> along? Apparently I was in some weird state when I tried to push.
>>>
>>> Ishan: Many apologies, but I'll have to push again, is it too late to
>>> re-spin?
>>>
>>> On Sat, Oct 14, 2017 at 7:56 AM, Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>>
 Here are the logs of two failed runs, FYI.
 http://textsearch.io/tests.log.gz (kernel: 4.13.5-200.fc26.x86_64)
 http://textsearch.io/tests2.log.gz (kernel: 4.13.5-200.fc26.x86_64)

 On Sat, Oct 14, 2017 at 8:15 PM, Ishan Chattopadhyaya <
 ichattopadhy...@gmail.com> wrote:

> FYI, I've been struggling to run tests for past 4-5 hours. About 10-15
> of them failed on every run; I tried all the branches, variety of 
> different
> machines (Intel i7 Haswell-E, Ryzen 1700, Threadripper 1950X). My JDK
> version on all of these are 8u144.
>
> Finally, figured out that all my machines had the latest
> 4.12.14-300.fc26.x86_64 or 4.13.5-200.fc26.x86_64 kernels. When I
> downgraded the kernel to 4.11.6-201.fc25.x86_64, the tests started running
> as usual. Now, I'll try to build the RC for 6.6.2 on this kernel. Is this 
> a
> known issue?
>
> On Sat, Oct 14, 2017 at 6:26 AM, Erick Erickson <
> erickerick...@gmail.com> wrote:
>
>> Done both for 6.6 and 6x
>>
>> On Fri, Oct 13, 2017 at 5:16 PM, Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> Sure Erick, please go ahead.
>>> I'll start the release later today.
>>> Thanks,
>>> Ishan
>>>
>>> On Sat, Oct 14, 2017 at 5:44 AM, Erick Erickson <
>>> erickerick...@gmail.com> wrote:
>>>
 Ishan:

 I have 11297 ready to rock-n-roll, it's just a matter of pushing
 it. Give me a few.

 The thing I'm not clear on is what to do with CHANGES.txt.
 Currently it's in 7.0.1 and 7.1.

 I propose adding a 6.6.2 section to 6x and including it there and
 leaving it in the 7.0.1 and 7.1 sections of master.

 I'll do it that way, you can change it if you want unless I hear
 back from you sooner.

 Erick

 On Fri, Oct 13, 2017 at 4:59 PM, Allison, Timothy B. <
 talli...@mitre.org> wrote:

> Sounds good.  Thank you!
>
>
>
> *From:* Ishan Chattopadhyaya [mailto:ichattopadhy...@gmail.com]
> *Sent:* Friday, October 13, 2017 5:25 PM
> *To:* dev@lucene.apache.org
> *Subject:* Re: 6.6.2 Release
>
>
>
> > Any chance we could get SOLR-11450 in?  I understand if the
> answer is no. 
>
> Currently, I want to have this release out as soon as possible so
> as to mitigate the risk exposure of the security vulnerability. Since 
> this
> is not committed yet, I'd vote for leaving this out and possibly 
> having it
> included in a later release, if needed.
>
> +1 to SOLR-11297.
>
>
>
>
>
> On Sat, Oct 14, 2017 at 2:32 AM, David Smiley <
> david.w.smi...@gmail.com> wrote:
>
> Suggested criteria for bug-fix release issues:
>
> * fixes a bug :-) and doesn't harm backwards-compatibility in
> the process
>
> * helps users upgrade to later versions
>
> * documentation
>
>
>
> +1 to SOLR-11297
>
>
>
> I'm not sure on SOLR-11450.  Seems it might introduce a
> back-compat issue?
>
>
>
> On Fri, Oct 13, 2017 at 4:40 PM Erick Erickson <
> erickerick...@gmail.com> wrote:
>
> I'd also like to get SOLR-11297 in if there are no objections.
> Ditto if the answer is no
>
>
>
> It's quite a safe fix though.
>
>
>
>
>
>
>
> On Fri, Oct 13, 2017 at 1:26 PM, Allison, Timothy B. <
> talli...@mitre.org> wrote:
>
> Any chance we could get SOLR-11450 in?  I understand if the answer
> is no. 
>
>
>
> Thank you!
>
>
>
> *From:* Ishan Chattopadhyaya [mailto:ichattopadhy...@gmail.com]
> *Sent:* Friday, October 13, 2017 4:23 PM
> *To:* 

[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-11444:
---

IIRC, that test in SOLR-11218 _used_ to work in which case the behavior is now 
different (and, I think, correct). Of course I may be mis-remembering...

Let's claim I'm remembering correctly for a second though: the test 
{{testDeleteAliasWithExistingCollectionName}} used to work but was only showing 
incorrect behavior. That lends weight to the discussions in SOLR-11488 and 
SOLR-11489 I think. At least we should beef up the tests a _lot_ to have faith 
that
1> the behavior is what we expect
2> future changes don't unexpectedly break things
I'd prefer a more systemic change of course.

To be clear, the discussions at SOLR-11488 and SOLR-11489 should _not_ hold up 
this JIRA. In fact I'd be loathe to do either of them before this one is 
committed.

And on a side note, WDYT about including the bits from SOLR-11488 that 
dis-allows deleting a collection if _any_ alias points to it in this JIRA? The 
nocommit test {{testDeleteOneOfTwoCollectionsAliased}} in SOLR-11218 exercises 
that and IIRC we get an error if we query on an alias after deleting only one 
of the collections pointed to by it.

> Improve Aliases.java and comma delimited collection list handling
> -
>
> Key: SOLR-11444
> URL: https://issues.apache.org/jira/browse/SOLR-11444
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_11444_Aliases.patch, SOLR_11444_Aliases.patch
>
>
> While starting to look at SOLR-11299 I noticed some brittleness in 
> assumptions about Strings that refer to a collection.  Sometimes they are in 
> fact references to comma separated lists, which appears was added with the 
> introduction of collection aliases (an alias can refer to a comma delimited 
> list).  So Java's type system kind of goes out the window when we do this.  
> In one case this leads to a bug -- CloudSolrClient will throw an NPE if you 
> try to write to such an alias.  Sending an update via HTTP will allow it and 
> send it to the first in the list.
> So this issue is about refactoring and some little improvements pertaining to 
> Aliases.java plus certain key spots that deal with collection references.  I 
> don't think I want to go as far as changing the public SolrJ API except to 
> adding documentation on what's possible.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11489) Create collections as _foo and auto-create an alias foo->_foo

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-11489:
---

Only one of these JIRAs should be implemented. We'll close the one not 
implemented as "is superceded by" or something.

> Create collections as _foo and auto-create an alias foo->_foo
> -
>
> Key: SOLR-11489
> URL: https://issues.apache.org/jira/browse/SOLR-11489
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>
> Spin-off from SOLR-11488. Currently if a collection and an alias have the 
> same name we don't test how they're resolved. So an innocent change to the 
> code could easily change the behavior (what happens when you have a 
> collection old, and an alias old->new and delete collection "old"? Have we 
> even defined what _should_ happen?).
> See the discussion at SOLR-11488.
> An alternative proposal to SOLR-11488 (thanks Varun for pointing it out) is 
> when creating a collection "foo", actually name it _foo and create an alias 
> foo->_foo. Also don't allow the user to create an alias that begins with an 
> underscore (and maybe the same for collections? An alias _foo->__foo starts 
> to get weird).
> The result would be we'd never have a collection and an alias with the same 
> name, which would go a long way to prevent issues going forward.
> This requires we consider the name in state.json to be an implementation 
> detail, but the user won't notice. Potential here for the list of aliases to 
> be quite large.
> Of course the user could still reference the collection directly as _foo if 
> they insisted.
> Establishing this JIRA for discussion of the alternatives.
> Assigning to myself to keep it from getting lost, feel free to take it over 
> if you'd like.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11489) Create collections as _foo and auto-create an alias foo->_foo

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-11489:
-

 Summary: Create collections as _foo and auto-create an alias 
foo->_foo
 Key: SOLR-11489
 URL: https://issues.apache.org/jira/browse/SOLR-11489
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Erick Erickson
Assignee: Erick Erickson


Spin-off from SOLR-11488. Currently if a collection and an alias have the same 
name we don't test how they're resolved. So an innocent change to the code 
could easily change the behavior (what happens when you have a collection old, 
and an alias old->new and delete collection "old"? Have we even defined what 
_should_ happen?).

See the discussion at SOLR-11488.

An alternative proposal to SOLR-11488 (thanks Varun for pointing it out) is 
when creating a collection "foo", actually name it _foo and create an alias 
foo->_foo. Also don't allow the user to create an alias that begins with an 
underscore (and maybe the same for collections? An alias _foo->__foo starts to 
get weird).

The result would be we'd never have a collection and an alias with the same 
name, which would go a long way to prevent issues going forward.

This requires we consider the name in state.json to be an implementation 
detail, but the user won't notice. Potential here for the list of aliases to be 
quite large.

Of course the user could still reference the collection directly as _foo if 
they insisted.

Establishing this JIRA for discussion of the alternatives.

Assigning to myself to keep it from getting lost, feel free to take it over if 
you'd like.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

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

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.request.TestV2Request

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.client.solrj.request.TestV2Request: 1) Thread[id=460, 
name=Connection evictor, state=TIMED_WAITING, group=TGRP-TestV2Request] 
at java.lang.Thread.sleep(Native Method) at 
org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.lang.Thread.run(Thread.java:748)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.client.solrj.request.TestV2Request: 
   1) Thread[id=460, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-TestV2Request]
at java.lang.Thread.sleep(Native Method)
at 
org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
at java.lang.Thread.run(Thread.java:748)
at __randomizedtesting.SeedInfo.seed([935E73214287F971]:0)


FAILED:  org.apache.solr.client.solrj.request.TestV2Request.testHttpSolrClient

Error Message:
Error from server at https://127.0.0.1:44755/solr: create the collection time 
out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException: 
Error from server at https://127.0.0.1:44755/solr: create the collection time 
out:180s
at 
__randomizedtesting.SeedInfo.seed([935E73214287F971:4B466B0BE3B3EB56]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:603)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.client.solrj.request.TestV2Request.assertSuccess(TestV2Request.java:42)
at 
org.apache.solr.client.solrj.request.TestV2Request.doTest(TestV2Request.java:72)
at 
org.apache.solr.client.solrj.request.TestV2Request.testHttpSolrClient(TestV2Request.java:62)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 

[jira] [Commented] (SOLR-11488) Do not allow collections and aliases to have the same name

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-11488:
---

bq: Do you mean someone wants to delete data or add data and it ends up in the 
wrong collection?

Well, that's possible too, it's not the case I was worrying about though. I 
mean if the code changes such that the delete collection logic follows the 
alias the new collection would get deleted.

At this point, having an alias that's the same name as a collection only does 
the right thing on delete by chance and there are no safeguards in the test 
suite insuring that behavior. Some innocent change could very easily delete the 
wrong collection!

Interesting idea (the underscore bit). Off the top of my head, it would solve 
the ambiguity problem. Under the covers, it has similar way of eliminating 
problems: there would never be a collection and an alias with the same name.

I guess there'd be some heartburn because the state.json file would have the 
underscore, but we've already changed the shard naming convention and as long 
as the users didn't notice (since they could use "foo") that would be an 
implementation detail. 

There's a little additional  level of indirection, we have clients with 1000's 
of collections. Does that matter enough to worry about? I suppose if someone 
really wanted to not use the aliases, they could reference the collection name 
with the underscore, and then if they told us "we can't use aliases for 
reindexing because all our applications use _foo" I wouldn't be too sympathetic.

I think it boils down to whether we're willing to tell people "in order to 
re-index, you have to create an alias to your old collection first and have 
your client use that". I'm waffling frankly. I just know that there'll be some 
clients who'll reply "we can't change the client". This can still be worked 
around, but would take more effort, to whit:
> create your new collection and index
> plan a service interruption
> delete the old collection (backup first!)
> create an alias with the old collection name pointing to the new collection.

I don't particularly like this as it takes away the fallback of going back to 
the old collection.  It'd work though.

I suppose the alternative is to leave things as they are and create a boatload 
of tests that insure that aliases take precedence over names everywhere, 
everywhen. Updates, deletes, collection admin operations, queries, basically 
anywhere we operate on a collection by name. I'd _much_ rather have a systemic 
fix, either this JIRA or your idea (or some other for that matter).

I'm going to create a new JIRA for the underscore idea and link it here so we 
can track them separately.

> Do not allow collections and aliases to have the same name
> --
>
> Key: SOLR-11488
> URL: https://issues.apache.org/jira/browse/SOLR-11488
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-11488.patch
>
>
> Currently you can define an alias with the same name as a collection and 
> (perhaps) vice-versa. The more I think about this the worse idea it seems. 
> See the discussion at the linked JIRAs.
> Proposal: We should fail to create a collection if an alias already exists 
> with the same name and vice-versa.
> This should depend on SOLR-11444 and supersede SOLR-11218, this JIRA will 
> include tests that define the intended behavior making SOLR-11218 obsolete. 
> We'll close SOLR-11218 as "contained by" this JIRA.
> This _will_ take away the ability to
> 1> create a collection, call it "old" and index to it.
> 2> decide you want to change the schema
> 3> create a collection call it "new" and index to it.
> 4> create an alias old->new THIS WILL FAIL.
> 5> delete the "old" collection
> People will have to create an alias pointing to "old" and change their 
> clients to use it, then they can do step 4 above
> This is kind of a pain, but much better than following an alias and deleting 
> "new". I'd also argue that it's a maintenance problem to have collections and 
> aliases with the same name.
> What do people think? I'll try to work up a preliminary patch. If we do this, 
> we should probably coordinate committing this and SOLR-11444 and I'll also 
> change the docs to reflect this and upgrade notes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: 6.6.2 Release

[Ishan Chattopadhyaya]

No problem, I'll pick up your commit. :-)

On Sat, Oct 14, 2017 at 8:51 PM, Erick Erickson 
wrote:

> Committed now.
>
>
>
> On Sat, Oct 14, 2017 at 8:19 AM, Erick Erickson 
> wrote:
>
>> Michael: Good catch. Have I mentioned lately that Git and I don't get
>> along? Apparently I was in some weird state when I tried to push.
>>
>> Ishan: Many apologies, but I'll have to push again, is it too late to
>> re-spin?
>>
>> On Sat, Oct 14, 2017 at 7:56 AM, Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> Here are the logs of two failed runs, FYI.
>>> http://textsearch.io/tests.log.gz (kernel: 4.13.5-200.fc26.x86_64)
>>> http://textsearch.io/tests2.log.gz (kernel: 4.13.5-200.fc26.x86_64)
>>>
>>> On Sat, Oct 14, 2017 at 8:15 PM, Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>>
 FYI, I've been struggling to run tests for past 4-5 hours. About 10-15
 of them failed on every run; I tried all the branches, variety of different
 machines (Intel i7 Haswell-E, Ryzen 1700, Threadripper 1950X). My JDK
 version on all of these are 8u144.

 Finally, figured out that all my machines had the latest
 4.12.14-300.fc26.x86_64 or 4.13.5-200.fc26.x86_64 kernels. When I
 downgraded the kernel to 4.11.6-201.fc25.x86_64, the tests started running
 as usual. Now, I'll try to build the RC for 6.6.2 on this kernel. Is this a
 known issue?

 On Sat, Oct 14, 2017 at 6:26 AM, Erick Erickson <
 erickerick...@gmail.com> wrote:

> Done both for 6.6 and 6x
>
> On Fri, Oct 13, 2017 at 5:16 PM, Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> Sure Erick, please go ahead.
>> I'll start the release later today.
>> Thanks,
>> Ishan
>>
>> On Sat, Oct 14, 2017 at 5:44 AM, Erick Erickson <
>> erickerick...@gmail.com> wrote:
>>
>>> Ishan:
>>>
>>> I have 11297 ready to rock-n-roll, it's just a matter of pushing it.
>>> Give me a few.
>>>
>>> The thing I'm not clear on is what to do with CHANGES.txt. Currently
>>> it's in 7.0.1 and 7.1.
>>>
>>> I propose adding a 6.6.2 section to 6x and including it there and
>>> leaving it in the 7.0.1 and 7.1 sections of master.
>>>
>>> I'll do it that way, you can change it if you want unless I hear
>>> back from you sooner.
>>>
>>> Erick
>>>
>>> On Fri, Oct 13, 2017 at 4:59 PM, Allison, Timothy B. <
>>> talli...@mitre.org> wrote:
>>>
 Sounds good.  Thank you!



 *From:* Ishan Chattopadhyaya [mailto:ichattopadhy...@gmail.com]
 *Sent:* Friday, October 13, 2017 5:25 PM
 *To:* dev@lucene.apache.org
 *Subject:* Re: 6.6.2 Release



 > Any chance we could get SOLR-11450 in?  I understand if the
 answer is no. 

 Currently, I want to have this release out as soon as possible so
 as to mitigate the risk exposure of the security vulnerability. Since 
 this
 is not committed yet, I'd vote for leaving this out and possibly 
 having it
 included in a later release, if needed.

 +1 to SOLR-11297.





 On Sat, Oct 14, 2017 at 2:32 AM, David Smiley <
 david.w.smi...@gmail.com> wrote:

 Suggested criteria for bug-fix release issues:

 * fixes a bug :-) and doesn't harm backwards-compatibility in
 the process

 * helps users upgrade to later versions

 * documentation



 +1 to SOLR-11297



 I'm not sure on SOLR-11450.  Seems it might introduce a back-compat
 issue?



 On Fri, Oct 13, 2017 at 4:40 PM Erick Erickson <
 erickerick...@gmail.com> wrote:

 I'd also like to get SOLR-11297 in if there are no objections.
 Ditto if the answer is no



 It's quite a safe fix though.







 On Fri, Oct 13, 2017 at 1:26 PM, Allison, Timothy B. <
 talli...@mitre.org> wrote:

 Any chance we could get SOLR-11450 in?  I understand if the answer
 is no. 



 Thank you!



 *From:* Ishan Chattopadhyaya [mailto:ichattopadhy...@gmail.com]
 *Sent:* Friday, October 13, 2017 4:23 PM
 *To:* dev@lucene.apache.org
 *Subject:* 6.6.2 Release



 Hi,

 In light of [0], we need a 6.6.2 release as soon as possible.

 I'd like to volunteer to RM for this release, unless someone else
 wants to do so or has an objection.

 Regards,

[JENKINS] Lucene-Solr-7.1-Linux (32bit/jdk1.8.0_144) - Build # 3 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.1-Linux/3/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.handler.TestSolrConfigHandlerCloud.test

Error Message:
Could not get expected value  'CY val' for path 'response/params/y/c' full 
output: {   "responseHeader":{ "status":0, "QTime":0},   "response":{   
  "znodeVersion":0, "params":{"x":{ "a":"A val", "b":"B 
val", "":{"v":0},  from server:  
https://127.0.0.1:41049/collection1_shard1_replica_n47

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val' for path 
'response/params/y/c' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "response":{
"znodeVersion":0,
"params":{"x":{
"a":"A val",
"b":"B val",
"":{"v":0},  from server:  
https://127.0.0.1:41049/collection1_shard1_replica_n47
at 
__randomizedtesting.SeedInfo.seed([D140EFBD8F65A717:5914D0672199CAEF]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:557)
at 
org.apache.solr.handler.TestSolrConfigHandlerCloud.testReqParams(TestSolrConfigHandlerCloud.java:206)
at 
org.apache.solr.handler.TestSolrConfigHandlerCloud.test(TestSolrConfigHandlerCloud.java:68)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

Re: 6.6.2 Release

[Erick Erickson]

Committed now.



On Sat, Oct 14, 2017 at 8:19 AM, Erick Erickson 
wrote:

> Michael: Good catch. Have I mentioned lately that Git and I don't get
> along? Apparently I was in some weird state when I tried to push.
>
> Ishan: Many apologies, but I'll have to push again, is it too late to
> re-spin?
>
> On Sat, Oct 14, 2017 at 7:56 AM, Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> Here are the logs of two failed runs, FYI.
>> http://textsearch.io/tests.log.gz (kernel: 4.13.5-200.fc26.x86_64)
>> http://textsearch.io/tests2.log.gz (kernel: 4.13.5-200.fc26.x86_64)
>>
>> On Sat, Oct 14, 2017 at 8:15 PM, Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> FYI, I've been struggling to run tests for past 4-5 hours. About 10-15
>>> of them failed on every run; I tried all the branches, variety of different
>>> machines (Intel i7 Haswell-E, Ryzen 1700, Threadripper 1950X). My JDK
>>> version on all of these are 8u144.
>>>
>>> Finally, figured out that all my machines had the latest
>>> 4.12.14-300.fc26.x86_64 or 4.13.5-200.fc26.x86_64 kernels. When I
>>> downgraded the kernel to 4.11.6-201.fc25.x86_64, the tests started running
>>> as usual. Now, I'll try to build the RC for 6.6.2 on this kernel. Is this a
>>> known issue?
>>>
>>> On Sat, Oct 14, 2017 at 6:26 AM, Erick Erickson >> > wrote:
>>>
 Done both for 6.6 and 6x

 On Fri, Oct 13, 2017 at 5:16 PM, Ishan Chattopadhyaya <
 ichattopadhy...@gmail.com> wrote:

> Sure Erick, please go ahead.
> I'll start the release later today.
> Thanks,
> Ishan
>
> On Sat, Oct 14, 2017 at 5:44 AM, Erick Erickson <
> erickerick...@gmail.com> wrote:
>
>> Ishan:
>>
>> I have 11297 ready to rock-n-roll, it's just a matter of pushing it.
>> Give me a few.
>>
>> The thing I'm not clear on is what to do with CHANGES.txt. Currently
>> it's in 7.0.1 and 7.1.
>>
>> I propose adding a 6.6.2 section to 6x and including it there and
>> leaving it in the 7.0.1 and 7.1 sections of master.
>>
>> I'll do it that way, you can change it if you want unless I hear back
>> from you sooner.
>>
>> Erick
>>
>> On Fri, Oct 13, 2017 at 4:59 PM, Allison, Timothy B. <
>> talli...@mitre.org> wrote:
>>
>>> Sounds good.  Thank you!
>>>
>>>
>>>
>>> *From:* Ishan Chattopadhyaya [mailto:ichattopadhy...@gmail.com]
>>> *Sent:* Friday, October 13, 2017 5:25 PM
>>> *To:* dev@lucene.apache.org
>>> *Subject:* Re: 6.6.2 Release
>>>
>>>
>>>
>>> > Any chance we could get SOLR-11450 in?  I understand if the answer
>>> is no. 
>>>
>>> Currently, I want to have this release out as soon as possible so as
>>> to mitigate the risk exposure of the security vulnerability. Since this 
>>> is
>>> not committed yet, I'd vote for leaving this out and possibly having it
>>> included in a later release, if needed.
>>>
>>> +1 to SOLR-11297.
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Oct 14, 2017 at 2:32 AM, David Smiley <
>>> david.w.smi...@gmail.com> wrote:
>>>
>>> Suggested criteria for bug-fix release issues:
>>>
>>> * fixes a bug :-) and doesn't harm backwards-compatibility in
>>> the process
>>>
>>> * helps users upgrade to later versions
>>>
>>> * documentation
>>>
>>>
>>>
>>> +1 to SOLR-11297
>>>
>>>
>>>
>>> I'm not sure on SOLR-11450.  Seems it might introduce a back-compat
>>> issue?
>>>
>>>
>>>
>>> On Fri, Oct 13, 2017 at 4:40 PM Erick Erickson <
>>> erickerick...@gmail.com> wrote:
>>>
>>> I'd also like to get SOLR-11297 in if there are no objections. Ditto
>>> if the answer is no
>>>
>>>
>>>
>>> It's quite a safe fix though.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Oct 13, 2017 at 1:26 PM, Allison, Timothy B. <
>>> talli...@mitre.org> wrote:
>>>
>>> Any chance we could get SOLR-11450 in?  I understand if the answer
>>> is no. 
>>>
>>>
>>>
>>> Thank you!
>>>
>>>
>>>
>>> *From:* Ishan Chattopadhyaya [mailto:ichattopadhy...@gmail.com]
>>> *Sent:* Friday, October 13, 2017 4:23 PM
>>> *To:* dev@lucene.apache.org
>>> *Subject:* 6.6.2 Release
>>>
>>>
>>>
>>> Hi,
>>>
>>> In light of [0], we need a 6.6.2 release as soon as possible.
>>>
>>> I'd like to volunteer to RM for this release, unless someone else
>>> wants to do so or has an objection.
>>>
>>> Regards,
>>>
>>> Ishan
>>>
>>>
>>>
>>> [0] - https://lucene.apache.org/solr/news.html#12-october-2017-ple
>>> ase-secure-your-apache-solr-servers-since-a-zero-day-exploit
>>> -has-been-reported-on-a-public-mailing-list
>>>
>>>
>>>
>>> --
>>>
>>> Lucene/Solr Search 

[jira] [Commented] (SOLR-11297) Message "Lock held by this virtual machine" during startup. Solr is trying to start some cores twice

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11297:


Commit 51e0959eaea9dd07ffd0cf6919d99c6b8eca7fa4 in lucene-solr's branch 
refs/heads/branch_6_6 from [~erickerickson]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=51e0959 ]

SOLR-11297: Message 'Lock held by this virtual machine' during startup.  Solr 
is trying to start some cores twice


> Message "Lock held by this virtual machine" during startup.  Solr is trying 
> to start some cores twice
> -
>
> Key: SOLR-11297
> URL: https://issues.apache.org/jira/browse/SOLR-11297
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
> Fix For: 7.0.1, 7.1
>
> Attachments: SOLR-11297.patch, SOLR-11297.patch, SOLR-11297.patch, 
> SOLR-11297.sh, solr6_6-startup.log
>
>
> Sometimes when Solr is restarted, I get some "lock held by this virtual 
> machine" messages in the log, and the admin UI has messages about a failure 
> to open a new searcher.  It doesn't happen on all cores, and the list of 
> cores that have the problem changes on subsequent restarts.  The cores that 
> exhibit the problems are working just fine -- the first core load is 
> successful, the failure to open a new searcher is on a second core load 
> attempt, which fails.
> None of the cores in the system are sharing an instanceDir or dataDir.  This 
> has been verified several times.
> The index is sharded manually, and the servers are not running in cloud mode.
> One critical detail to this issue: The cores are all perfectly functional.  
> If somebody is seeing an error message that results in a core not working at 
> all, then it is likely a different issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: 6.6.2 Release

[Erick Erickson]

Michael: Good catch. Have I mentioned lately that Git and I don't get
along? Apparently I was in some weird state when I tried to push.

Ishan: Many apologies, but I'll have to push again, is it too late to
re-spin?

On Sat, Oct 14, 2017 at 7:56 AM, Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Here are the logs of two failed runs, FYI.
> http://textsearch.io/tests.log.gz (kernel: 4.13.5-200.fc26.x86_64)
> http://textsearch.io/tests2.log.gz (kernel: 4.13.5-200.fc26.x86_64)
>
> On Sat, Oct 14, 2017 at 8:15 PM, Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> FYI, I've been struggling to run tests for past 4-5 hours. About 10-15 of
>> them failed on every run; I tried all the branches, variety of different
>> machines (Intel i7 Haswell-E, Ryzen 1700, Threadripper 1950X). My JDK
>> version on all of these are 8u144.
>>
>> Finally, figured out that all my machines had the latest
>> 4.12.14-300.fc26.x86_64 or 4.13.5-200.fc26.x86_64 kernels. When I
>> downgraded the kernel to 4.11.6-201.fc25.x86_64, the tests started running
>> as usual. Now, I'll try to build the RC for 6.6.2 on this kernel. Is this a
>> known issue?
>>
>> On Sat, Oct 14, 2017 at 6:26 AM, Erick Erickson 
>> wrote:
>>
>>> Done both for 6.6 and 6x
>>>
>>> On Fri, Oct 13, 2017 at 5:16 PM, Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>>
 Sure Erick, please go ahead.
 I'll start the release later today.
 Thanks,
 Ishan

 On Sat, Oct 14, 2017 at 5:44 AM, Erick Erickson <
 erickerick...@gmail.com> wrote:

> Ishan:
>
> I have 11297 ready to rock-n-roll, it's just a matter of pushing it.
> Give me a few.
>
> The thing I'm not clear on is what to do with CHANGES.txt. Currently
> it's in 7.0.1 and 7.1.
>
> I propose adding a 6.6.2 section to 6x and including it there and
> leaving it in the 7.0.1 and 7.1 sections of master.
>
> I'll do it that way, you can change it if you want unless I hear back
> from you sooner.
>
> Erick
>
> On Fri, Oct 13, 2017 at 4:59 PM, Allison, Timothy B. <
> talli...@mitre.org> wrote:
>
>> Sounds good.  Thank you!
>>
>>
>>
>> *From:* Ishan Chattopadhyaya [mailto:ichattopadhy...@gmail.com]
>> *Sent:* Friday, October 13, 2017 5:25 PM
>> *To:* dev@lucene.apache.org
>> *Subject:* Re: 6.6.2 Release
>>
>>
>>
>> > Any chance we could get SOLR-11450 in?  I understand if the answer
>> is no. 
>>
>> Currently, I want to have this release out as soon as possible so as
>> to mitigate the risk exposure of the security vulnerability. Since this 
>> is
>> not committed yet, I'd vote for leaving this out and possibly having it
>> included in a later release, if needed.
>>
>> +1 to SOLR-11297.
>>
>>
>>
>>
>>
>> On Sat, Oct 14, 2017 at 2:32 AM, David Smiley <
>> david.w.smi...@gmail.com> wrote:
>>
>> Suggested criteria for bug-fix release issues:
>>
>> * fixes a bug :-) and doesn't harm backwards-compatibility in the
>> process
>>
>> * helps users upgrade to later versions
>>
>> * documentation
>>
>>
>>
>> +1 to SOLR-11297
>>
>>
>>
>> I'm not sure on SOLR-11450.  Seems it might introduce a back-compat
>> issue?
>>
>>
>>
>> On Fri, Oct 13, 2017 at 4:40 PM Erick Erickson <
>> erickerick...@gmail.com> wrote:
>>
>> I'd also like to get SOLR-11297 in if there are no objections. Ditto
>> if the answer is no
>>
>>
>>
>> It's quite a safe fix though.
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Oct 13, 2017 at 1:26 PM, Allison, Timothy B. <
>> talli...@mitre.org> wrote:
>>
>> Any chance we could get SOLR-11450 in?  I understand if the answer is
>> no. 
>>
>>
>>
>> Thank you!
>>
>>
>>
>> *From:* Ishan Chattopadhyaya [mailto:ichattopadhy...@gmail.com]
>> *Sent:* Friday, October 13, 2017 4:23 PM
>> *To:* dev@lucene.apache.org
>> *Subject:* 6.6.2 Release
>>
>>
>>
>> Hi,
>>
>> In light of [0], we need a 6.6.2 release as soon as possible.
>>
>> I'd like to volunteer to RM for this release, unless someone else
>> wants to do so or has an objection.
>>
>> Regards,
>>
>> Ishan
>>
>>
>>
>> [0] - https://lucene.apache.org/solr/news.html#12-october-2017-ple
>> ase-secure-your-apache-solr-servers-since-a-zero-day-exploit
>> -has-been-reported-on-a-public-mailing-list
>>
>>
>>
>> --
>>
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
>>
>>
>
>

>>>
>>
>

Re: 6.6.2 Release

[Ishan Chattopadhyaya]

Here are the logs of two failed runs, FYI.
http://textsearch.io/tests.log.gz (kernel: 4.13.5-200.fc26.x86_64)
http://textsearch.io/tests2.log.gz (kernel: 4.13.5-200.fc26.x86_64)

On Sat, Oct 14, 2017 at 8:15 PM, Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> FYI, I've been struggling to run tests for past 4-5 hours. About 10-15 of
> them failed on every run; I tried all the branches, variety of different
> machines (Intel i7 Haswell-E, Ryzen 1700, Threadripper 1950X). My JDK
> version on all of these are 8u144.
>
> Finally, figured out that all my machines had the latest
> 4.12.14-300.fc26.x86_64 or 4.13.5-200.fc26.x86_64 kernels. When I
> downgraded the kernel to 4.11.6-201.fc25.x86_64, the tests started running
> as usual. Now, I'll try to build the RC for 6.6.2 on this kernel. Is this a
> known issue?
>
> On Sat, Oct 14, 2017 at 6:26 AM, Erick Erickson 
> wrote:
>
>> Done both for 6.6 and 6x
>>
>> On Fri, Oct 13, 2017 at 5:16 PM, Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> Sure Erick, please go ahead.
>>> I'll start the release later today.
>>> Thanks,
>>> Ishan
>>>
>>> On Sat, Oct 14, 2017 at 5:44 AM, Erick Erickson >> > wrote:
>>>
 Ishan:

 I have 11297 ready to rock-n-roll, it's just a matter of pushing it.
 Give me a few.

 The thing I'm not clear on is what to do with CHANGES.txt. Currently
 it's in 7.0.1 and 7.1.

 I propose adding a 6.6.2 section to 6x and including it there and
 leaving it in the 7.0.1 and 7.1 sections of master.

 I'll do it that way, you can change it if you want unless I hear back
 from you sooner.

 Erick

 On Fri, Oct 13, 2017 at 4:59 PM, Allison, Timothy B. <
 talli...@mitre.org> wrote:

> Sounds good.  Thank you!
>
>
>
> *From:* Ishan Chattopadhyaya [mailto:ichattopadhy...@gmail.com]
> *Sent:* Friday, October 13, 2017 5:25 PM
> *To:* dev@lucene.apache.org
> *Subject:* Re: 6.6.2 Release
>
>
>
> > Any chance we could get SOLR-11450 in?  I understand if the answer
> is no. 
>
> Currently, I want to have this release out as soon as possible so as
> to mitigate the risk exposure of the security vulnerability. Since this is
> not committed yet, I'd vote for leaving this out and possibly having it
> included in a later release, if needed.
>
> +1 to SOLR-11297.
>
>
>
>
>
> On Sat, Oct 14, 2017 at 2:32 AM, David Smiley <
> david.w.smi...@gmail.com> wrote:
>
> Suggested criteria for bug-fix release issues:
>
> * fixes a bug :-) and doesn't harm backwards-compatibility in the
> process
>
> * helps users upgrade to later versions
>
> * documentation
>
>
>
> +1 to SOLR-11297
>
>
>
> I'm not sure on SOLR-11450.  Seems it might introduce a back-compat
> issue?
>
>
>
> On Fri, Oct 13, 2017 at 4:40 PM Erick Erickson <
> erickerick...@gmail.com> wrote:
>
> I'd also like to get SOLR-11297 in if there are no objections. Ditto
> if the answer is no
>
>
>
> It's quite a safe fix though.
>
>
>
>
>
>
>
> On Fri, Oct 13, 2017 at 1:26 PM, Allison, Timothy B. <
> talli...@mitre.org> wrote:
>
> Any chance we could get SOLR-11450 in?  I understand if the answer is
> no. 
>
>
>
> Thank you!
>
>
>
> *From:* Ishan Chattopadhyaya [mailto:ichattopadhy...@gmail.com]
> *Sent:* Friday, October 13, 2017 4:23 PM
> *To:* dev@lucene.apache.org
> *Subject:* 6.6.2 Release
>
>
>
> Hi,
>
> In light of [0], we need a 6.6.2 release as soon as possible.
>
> I'd like to volunteer to RM for this release, unless someone else
> wants to do so or has an objection.
>
> Regards,
>
> Ishan
>
>
>
> [0] - https://lucene.apache.org/solr/news.html#12-october-2017-ple
> ase-secure-your-apache-solr-servers-since-a-zero-day-exploit
> -has-been-reported-on-a-public-mailing-list
>
>
>
> --
>
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
>
>


>>>
>>
>

Re: 6.6.2 Release

[Ishan Chattopadhyaya]

FYI, I've been struggling to run tests for past 4-5 hours. About 10-15 of
them failed on every run; I tried all the branches, variety of different
machines (Intel i7 Haswell-E, Ryzen 1700, Threadripper 1950X). My JDK
version on all of these are 8u144.

Finally, figured out that all my machines had the latest
4.12.14-300.fc26.x86_64 or 4.13.5-200.fc26.x86_64 kernels. When I
downgraded the kernel to 4.11.6-201.fc25.x86_64, the tests started running
as usual. Now, I'll try to build the RC for 6.6.2 on this kernel. Is this a
known issue?

On Sat, Oct 14, 2017 at 6:26 AM, Erick Erickson 
wrote:

> Done both for 6.6 and 6x
>
> On Fri, Oct 13, 2017 at 5:16 PM, Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> Sure Erick, please go ahead.
>> I'll start the release later today.
>> Thanks,
>> Ishan
>>
>> On Sat, Oct 14, 2017 at 5:44 AM, Erick Erickson 
>> wrote:
>>
>>> Ishan:
>>>
>>> I have 11297 ready to rock-n-roll, it's just a matter of pushing it.
>>> Give me a few.
>>>
>>> The thing I'm not clear on is what to do with CHANGES.txt. Currently
>>> it's in 7.0.1 and 7.1.
>>>
>>> I propose adding a 6.6.2 section to 6x and including it there and
>>> leaving it in the 7.0.1 and 7.1 sections of master.
>>>
>>> I'll do it that way, you can change it if you want unless I hear back
>>> from you sooner.
>>>
>>> Erick
>>>
>>> On Fri, Oct 13, 2017 at 4:59 PM, Allison, Timothy B. >> > wrote:
>>>
 Sounds good.  Thank you!



 *From:* Ishan Chattopadhyaya [mailto:ichattopadhy...@gmail.com]
 *Sent:* Friday, October 13, 2017 5:25 PM
 *To:* dev@lucene.apache.org
 *Subject:* Re: 6.6.2 Release



 > Any chance we could get SOLR-11450 in?  I understand if the answer is
 no. 

 Currently, I want to have this release out as soon as possible so as to
 mitigate the risk exposure of the security vulnerability. Since this is not
 committed yet, I'd vote for leaving this out and possibly having it
 included in a later release, if needed.

 +1 to SOLR-11297.





 On Sat, Oct 14, 2017 at 2:32 AM, David Smiley 
 wrote:

 Suggested criteria for bug-fix release issues:

 * fixes a bug :-) and doesn't harm backwards-compatibility in the
 process

 * helps users upgrade to later versions

 * documentation



 +1 to SOLR-11297



 I'm not sure on SOLR-11450.  Seems it might introduce a back-compat
 issue?



 On Fri, Oct 13, 2017 at 4:40 PM Erick Erickson 
 wrote:

 I'd also like to get SOLR-11297 in if there are no objections. Ditto if
 the answer is no



 It's quite a safe fix though.







 On Fri, Oct 13, 2017 at 1:26 PM, Allison, Timothy B. <
 talli...@mitre.org> wrote:

 Any chance we could get SOLR-11450 in?  I understand if the answer is
 no. 



 Thank you!



 *From:* Ishan Chattopadhyaya [mailto:ichattopadhy...@gmail.com]
 *Sent:* Friday, October 13, 2017 4:23 PM
 *To:* dev@lucene.apache.org
 *Subject:* 6.6.2 Release



 Hi,

 In light of [0], we need a 6.6.2 release as soon as possible.

 I'd like to volunteer to RM for this release, unless someone else wants
 to do so or has an objection.

 Regards,

 Ishan



 [0] - https://lucene.apache.org/solr/news.html#12-october-2017-ple
 ase-secure-your-apache-solr-servers-since-a-zero-day-exploit
 -has-been-reported-on-a-public-mailing-list



 --

 Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker

 LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
 http://www.solrenterprisesearchserver.com



>>>
>>>
>>
>

[jira] [Commented] (SOLR-11362) Solr Cloud SSL handshake_failure keystore (SOLR_SSL_KEY_STORE) multiple certs issue

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-11362:
-

{quote}
1) Why does this setup work with Kafka and not Solr if the java classes used 
should be very similar?
2) Why can't I use multiple keys/certs in the keystore? Is this expected 
functionality?
{quote}

For Kafka are you specifying the alias of the entry in the JKS? My guess is 
that the alias needs to be specified so Solr knows which entry in the JKS to 
pick up.

{quote}
3) Are there any plans to add parameters for SSL/TLS version selection and 
cipher selection?
{quote}

The solr.in.sh variables (SOLR_SSL_*) are wrappers for Java properties for 
Jetty usually. The solr.jetty Java properties are used in jetty-ssl to setup 
Jetty.

* https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L162
* 
https://github.com/apache/lucene-solr/blob/master/solr/server/etc/jetty-ssl.xml

You should be able to set the Jetty SSL/TLS version and cipher selection as 
properties that Jetty would pick up through jetty-ssl.xml. It would be 
something to try. If you get it to work please update this ticket. The 
documentation can always be improved.

For reference here are some links about Jetty SSL/TLS configuration which 
should help point you in the right direction:
* 
https://stackoverflow.com/questions/10425306/if-theres-more-than-one-certificate-in-jettys-key-store-how-does-it-choose
** This states that an alias should be specified or it tries to guess the right 
alias to use.
* 
http://www.eclipse.org/jetty/documentation/current/configuring-ssl.html#configuring-sslcontextfactory-cipherSuites

> Solr Cloud SSL handshake_failure keystore (SOLR_SSL_KEY_STORE) multiple certs 
> issue
> ---
>
> Key: SOLR-11362
> URL: https://issues.apache.org/jira/browse/SOLR-11362
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 6.6
> Environment: CentOS 7.3, Virtual Machines, AWS. 
>Reporter: Calvin Hartwell
>Priority: Minor
>
> Hey all,
> I ran into a strange scenario recently so I thought I'd share, it was very 
> frustrating and I only discovered the fix on a whim. 
> Let's imagine I have three nodes which form a solrcloud: 
> - node0.someaddress.com
> - node1.someaddress.com
> - node2.someaddress.com 
> Each of these machines has an SSL key and csr generated which is signed by a 
> CA. The truststore contains the public certificate of the CA (defined as per 
> manual using SOLR_SSL_TRUST_STORE). 
> The keystore (SOLR_SSL_KEY_STORE) contains three entries, one for the CA 
> public cert, and two entries for the server itself, with different alises 
> (one has the alias set to the FQDN, the other is set to localhost). 
> All parameters for SSL/TLS are configured correctly as per the solr manuals. 
> Obviously the keystore (SOLR_SSL_KEY_STORE) only needs the single 
> cert/private key for the server with no other entries, but this setup works 
> 100% with Kafka using the three entries. 
> Here is an example:
> keytool -list -keystore node0.jks 
> localhost ..(omitted)
> node0.someaddress.com ...(omitted)
> cacert ..(omitted)
> keytool -list -keystore node1.jks 
> localhost ..(omitted)
> cacert ..(omitted)
> node1.someaddress.com ...(omitted)
> keytool -list -keystore node2.jks 
> node2.someaddress.com ...(omitted)
> localhost ..(omitted)
> cacert ..(omitted)
> Here is the interesting part, with this setup, when the nodes are started 
> only 1/3 nodes starts correctly (in my case, node1.someaddress.com) all the 
> other nodes (node0.someaddress.com, node2.someaddress.com) have a 
> handshake_failure error. If you try to run solr status on the two broken 
> nodes it doesn't work but this command works fine for the working node. 
> I enabled the most detailed level of logging and monitored the handshake but 
> couldn't see anything really a miss, all the configuration properties were 
> set correctly. 
> What I noticed was this: when running keytool to list the keys for each 
> keystore, the certificates in the keystore were displayed in different orders 
> (as shown above) like they were sorted by alphabetical order by the keytool 
> cli tool. This gave me an idea to delete the rest of the certs in each 
> keystore for each node so they only had single entries for the fqdn.
> So the keystores now looked like this: 
> keytool -list -keystore solrkeystore.jks ...
> node0.someaddress.com ...(omitted)
> keytool -list -keystore solrkeystore.jks ...
> node1.someaddress.com ...(omitted)
> keytool -list -keystore solrkeystore.jks ...
> node2.someaddress.com ...(omitted)
> After I did this and restarted the solr nodes started 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/611/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  
org.apache.solr.cloud.TestCloudSearcherWarming.testRepFactor1LeaderStartup

Error Message:
 null Live Nodes: [127.0.0.1:46165_solr] Last available state: 
DocCollection(testRepFactor1LeaderStartup//collections/testRepFactor1LeaderStartup/state.json/4)={
   "pullReplicas":"0",   "replicationFactor":"1",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   
"replicas":{"core_node2":{   
"core":"testRepFactor1LeaderStartup_shard1_replica_n1",   
"base_url":"http://127.0.0.1:46165/solr;,   
"node_name":"127.0.0.1:46165_solr",   "state":"active",   
"type":"NRT",   "leader":"true",   "router":{"name":"compositeId"}, 
  "maxShardsPerNode":"1",   "autoAddReplicas":"false",   "nrtReplicas":"1",   
"tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: 
null
Live Nodes: [127.0.0.1:46165_solr]
Last available state: 
DocCollection(testRepFactor1LeaderStartup//collections/testRepFactor1LeaderStartup/state.json/4)={
  "pullReplicas":"0",
  "replicationFactor":"1",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{"core_node2":{
  "core":"testRepFactor1LeaderStartup_shard1_replica_n1",
  "base_url":"http://127.0.0.1:46165/solr;,
  "node_name":"127.0.0.1:46165_solr",
  "state":"active",
  "type":"NRT",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "nrtReplicas":"1",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([D9FB1BFAB7410EB5:ED35622A6A1475B]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269)
at 
org.apache.solr.cloud.TestCloudSearcherWarming.testRepFactor1LeaderStartup(TestCloudSearcherWarming.java:126)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 

[jira] [Commented] (LUCENE-7993) Speed up phrase queries when total hit count is not needed

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7993:
-

feel free to open separate issue for the sim testing/cleanup, i can try to 
assist with that stuff. I have done battle with many of these before over this 
same stuff.

> Speed up phrase queries when total hit count is not needed
> --
>
> Key: LUCENE-7993
> URL: https://issues.apache.org/jira/browse/LUCENE-7993
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7993.patch
>
>
> Follow-up of LUCENE-4100: When thinking about the API that we needed to 
> introduce to support MAXSCORE, I wondered whether the same API could support 
> other optimizations. The idea is that when running phrase queries, before we 
> start reading positions, we already have access to the term frequency of each 
> term. And the frequency of the phrase is bounded by the minimum term 
> frequency of the involved terms. So if the score for that minimum term 
> frequency is not competitive then it means that the score for the phrase is 
> not competitive either if we can assume that the score increases (or 
> stagnates) when the term freq increases, which sounds like an ok requirement 
> for a sane Similarity?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7993) Speed up phrase queries when total hit count is not needed

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7993:
-

ok, i get it, the optimization is ok since we actually call score for the doc 
with the theoretically maximum possible TF (taking its norm into account), just 
before reading positions.

Note that this optimization is definitely unsafe for some broken similarities 
(specifically the ones documented to be broken in this way, such as DFR model 
P), and probably also for certain parameters to e.g. DFR NormalizationXXX. 
Additionally some similarities (such as AxiomaticXYZ) are not in our random 
test framework, so its unknown there. We could use some explicit tests rather 
than relying on the test suite in that way, too.

But the requirement is 100% reasonable, we can't let some fundamentally broken 
formulas get in our way here :) I would go a step further and say that maybe 
these broken ones should move to the sandbox?

> Speed up phrase queries when total hit count is not needed
> --
>
> Key: LUCENE-7993
> URL: https://issues.apache.org/jira/browse/LUCENE-7993
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7993.patch
>
>
> Follow-up of LUCENE-4100: When thinking about the API that we needed to 
> introduce to support MAXSCORE, I wondered whether the same API could support 
> other optimizations. The idea is that when running phrase queries, before we 
> start reading positions, we already have access to the term frequency of each 
> term. And the frequency of the phrase is bounded by the minimum term 
> frequency of the involved terms. So if the score for that minimum term 
> frequency is not competitive then it means that the score for the phrase is 
> not competitive either if we can assume that the score increases (or 
> stagnates) when the term freq increases, which sounds like an ok requirement 
> for a sane Similarity?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7993) Speed up phrase queries when total hit count is not needed

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7993:
-

{quote}
if we can assume that the score increases (or stagnates) when the term freq 
increases, which sounds like an ok requirement for a sane Similarity?
{quote}

But what about length normalization?

> Speed up phrase queries when total hit count is not needed
> --
>
> Key: LUCENE-7993
> URL: https://issues.apache.org/jira/browse/LUCENE-7993
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7993.patch
>
>
> Follow-up of LUCENE-4100: When thinking about the API that we needed to 
> introduce to support MAXSCORE, I wondered whether the same API could support 
> other optimizations. The idea is that when running phrase queries, before we 
> start reading positions, we already have access to the term frequency of each 
> term. And the frequency of the phrase is bounded by the minimum term 
> frequency of the involved terms. So if the score for that minimum term 
> frequency is not competitive then it means that the score for the phrase is 
> not competitive either if we can assume that the score increases (or 
> stagnates) when the term freq increases, which sounds like an ok requirement 
> for a sane Similarity?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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/jdk1.8.0) - Build # 4225 - Still unstable!

[Policeman Jenkins Server]

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

78 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.BasicFunctionalityTest

Error Message:
org.apache.solr.BasicFunctionalityTest

Stack Trace:
java.lang.ClassNotFoundException: org.apache.solr.BasicFunctionalityTest
at java.net.URLClassLoader$1.run(URLClassLoader.java:370)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.instantiate(SlaveMain.java:280)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:240)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:368)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13)
Caused by: java.io.FileNotFoundException: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/classes/test/org/apache/solr/BasicFunctionalityTest.class
 (Too many open files)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:195)
at java.io.FileInputStream.(FileInputStream.java:138)
at 
sun.misc.URLClassPath$FileLoader$1.getInputStream(URLClassPath.java:1288)
at sun.misc.Resource.cachedInputStream(Resource.java:77)
at sun.misc.Resource.getByteBuffer(Resource.java:160)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:454)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
... 12 more


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

Error Message:
org.apache.solr.cloud.BasicDistributedZk2Test

Stack Trace:
java.lang.ClassNotFoundException: org.apache.solr.cloud.BasicDistributedZk2Test
at java.net.URLClassLoader$1.run(URLClassLoader.java:370)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.instantiate(SlaveMain.java:280)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:240)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:368)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13)
Caused by: java.io.FileNotFoundException: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/classes/test/org/apache/solr/cloud/BasicDistributedZk2Test.class
 (Too many open files)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:195)
at java.io.FileInputStream.(FileInputStream.java:138)
at 
sun.misc.URLClassPath$FileLoader$1.getInputStream(URLClassPath.java:1288)
at sun.misc.Resource.cachedInputStream(Resource.java:77)
at sun.misc.Resource.getByteBuffer(Resource.java:160)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:454)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
... 12 more


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

Error Message:
org.apache.solr.cloud.CdcrBootstrapTest

Stack Trace:
java.lang.ClassNotFoundException: org.apache.solr.cloud.CdcrBootstrapTest
at java.net.URLClassLoader$1.run(URLClassLoader.java:370)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at 

[jira] [Commented] (SOLR-11464) Unused code in DistributedUpdateProcessor

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-11464:
-

I have since run the core tests (where all the failures occurred) with the 
default number of processors (4 instead of 30) and they passed on 7 rounds of 
beast and fail on the 8th .. I had a similar result without the patch. 

> Unused code in DistributedUpdateProcessor
> -
>
> Key: SOLR-11464
> URL: https://issues.apache.org/jira/browse/SOLR-11464
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: master (8.0)
>Reporter: Gus Heck
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-11464.patch, unused.png
>
>
> While reading code I ran across a couple of suspicious unused 
> values/variables. Thought I would raise this so that folks can consider if 
> something was lost here, or if perhaps we can eliminate an unnecessary call 
> to zookeeper and tidy things up a bit. Screenshot and patch to eliminate 
> shortly...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10030) SolrClient.getById() method in Solrj doesn't retrieve child documents

[Frank Kelly (JIRA)]

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

Frank Kelly commented on SOLR-10030:


We are using nested  / child documents in Solr 5.3.1, any idea how "bad" this 
issue is in v6? Sounds like nested documents don't work at all.

> SolrClient.getById() method in Solrj doesn't retrieve child documents
> -
>
> Key: SOLR-10030
> URL: https://issues.apache.org/jira/browse/SOLR-10030
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java, SolrJ
>Affects Versions: 6.2.1
>Reporter:  Masoud Kiaeeha
>
> I have this code in my program which uses solrj:
> SolrDocument document = solrClient.getById(idString);
> List children = document.getChildDocuments();
> which returns null for document.getChildDocuments() although the document I 
> am referring to has children. I can easily confirm that this document has 
> children by running the following query:
> q={!child of="path:1.document"}path:1.document



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11299) Time partitioned collections (umbrella issue)

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-11299:
-

Ok I see your point about timezone. I wasn't thinking about the application of 
date math, which would still work if all was UTC but that would be very 
unfriendly to the user.

> Time partitioned collections (umbrella issue)
> -
>
> Key: SOLR-11299
> URL: https://issues.apache.org/jira/browse/SOLR-11299
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
>
> Solr ought to have the ability to manage large-scale time-series data (think 
> logs or sensor data / IOT) itself without a lot of manual/external work.  The 
> most naive and painless approach today is to create a collection with a high 
> numShards with hash routing but this isn't as good as partitioning the 
> underlying indexes by time for these reasons:
> * Easy to scale up/down horizontally as data/requirements change.  (No need 
> to over-provision, use shard splitting, or re-index with different config)
> * Faster queries: 
> ** can search fewer shards, reducing overall load
> ** realtime search is more tractable (since most shards are stable -- 
> good caches)
> ** "recent" shards (that might be queried more) can be allocated to 
> faster hardware
> ** aged out data is simply removed, not marked as deleted.  Deleted docs 
> still have search overhead.
> * Outages of a shard result in a degraded but sometimes a useful system 
> nonetheless (compare to random subset missing)
> Ideally you could set this up once and then simply work with a collection 
> (potentially actually an alias) in a normal way (search or update), letting 
> Solr handle the addition of new partitions, removing of old ones, and 
> appropriate routing of requests depending on their nature.
> This issue is an umbrella issue for the particular tasks that will make it 
> all happen -- either subtasks or issue linking.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11299) Time partitioned collections (umbrella issue)

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-11299:
-

I agree that millisecond names are not friendly :) and I did advocate cleaning 
that up in a second step in my comment... I'll look at SOLR-2690. My main worry 
about partition names being "the key" directly is the cost of 
DateFormat.parse() of some number of partition names for every doc... the non 
contiguous series would be an issue either way I suspect, and deleting 
collections in from the middle of your time series should be unsupported. 

> Time partitioned collections (umbrella issue)
> -
>
> Key: SOLR-11299
> URL: https://issues.apache.org/jira/browse/SOLR-11299
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
>
> Solr ought to have the ability to manage large-scale time-series data (think 
> logs or sensor data / IOT) itself without a lot of manual/external work.  The 
> most naive and painless approach today is to create a collection with a high 
> numShards with hash routing but this isn't as good as partitioning the 
> underlying indexes by time for these reasons:
> * Easy to scale up/down horizontally as data/requirements change.  (No need 
> to over-provision, use shard splitting, or re-index with different config)
> * Faster queries: 
> ** can search fewer shards, reducing overall load
> ** realtime search is more tractable (since most shards are stable -- 
> good caches)
> ** "recent" shards (that might be queried more) can be allocated to 
> faster hardware
> ** aged out data is simply removed, not marked as deleted.  Deleted docs 
> still have search overhead.
> * Outages of a shard result in a degraded but sometimes a useful system 
> nonetheless (compare to random subset missing)
> Ideally you could set this up once and then simply work with a collection 
> (potentially actually an alias) in a normal way (search or update), letting 
> Solr handle the addition of new partitions, removing of old ones, and 
> appropriate routing of requests depending on their nature.
> This issue is an umbrella issue for the particular tasks that will make it 
> all happen -- either subtasks or issue linking.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-6.6-Windows (64bit/jdk1.8.0_144) - Build # 63 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.6-Windows/63/
Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Something is broken in the assert for no shards using the same indexDir - 
probably something was changed in the attributes published in the MBean of 
SolrCore : {}

Stack Trace:
java.lang.AssertionError: Something is broken in the assert for no shards using 
the same indexDir - probably something was changed in the attributes published 
in the MBean of SolrCore : {}
at 
__randomizedtesting.SeedInfo.seed([FD0C192A3D38297E:B5796D9E3B0B06EB]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.checkNoTwoShardsUseTheSameIndexDir(CollectionsAPIDistributedZkTest.java:646)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:524)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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)

[JENKINS] Lucene-Solr-SmokeRelease-7.1 - Build # 2 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.1/2/

No tests ran.

Build Log:
[...truncated 28023 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.1/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.1/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.1/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.1/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.02 sec (14.4 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.1.0-src.tgz...
   [smoker] 30.9 MB in 0.08 sec (369.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.1.0.tgz...
   [smoker] 69.6 MB in 0.21 sec (335.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.1.0.zip...
   [smoker] 80.0 MB in 0.26 sec (309.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.1.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6221 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.1.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6221 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.1.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 213 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (64.1 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.1.0-src.tgz...
   [smoker] 52.7 MB in 0.22 sec (241.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.1.0.tgz...
   [smoker] 145.4 MB in 0.58 sec (249.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.1.0.zip...
   [smoker] 146.4 MB in 0.57 sec (258.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.1.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.1.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.1/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.1/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.1/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.1/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0-java8
   [smoker] Creating Solr home directory 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.1/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]   [|]   [/]   [-]   [\]  

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.analytics.facet.FieldFacetExtrasCloudTest

Error Message:
Error from server at http://127.0.0.1:36249/solr: create the collection time 
out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:36249/solr: create the collection time out:180s
at __randomizedtesting.SeedInfo.seed([A6C5485B1E9F96F7]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
at 
org.apache.solr.analytics.facet.AbstractAnalyticsFacetCloudTest.setupCluster(AbstractAnalyticsFacetCloudTest.java:58)
at 
org.apache.solr.analytics.facet.FieldFacetExtrasCloudTest.beforeClass(FieldFacetExtrasCloudTest.java:47)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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.hdfs.StressHdfsTest.test

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:36081/w/wq

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:36081/w/wq
at 
__randomizedtesting.SeedInfo.seed([3F478A1B310E0D70:B713B5C19FF26088]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:637)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6959/
Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseG1GC --illegal-access=deny

1 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testEventQueue

Error Message:
action wasn't interrupted

Stack Trace:
java.lang.AssertionError: action wasn't interrupted
at 
__randomizedtesting.SeedInfo.seed([644A706B4030B2C1:ADFF32C549577434]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testEventQueue(TriggerIntegrationTest.java:684)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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)




Build Log:
[...truncated 12634 lines...]
   [junit4] Suite: org.apache.solr.cloud.autoscaling.TriggerIntegrationTest
   [junit4]   2> 1405757 INFO  
(SUITE-TriggerIntegrationTest-seed#[644A706B4030B2C1]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 

[GitHub] lucene-solr pull request #262: SOLR-11443: Remove the usage of workqueue for...

[asfgit]

Github user asfgit closed the pull request at:

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


---

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

[jira] [Commented] (SOLR-11443) Remove the usage of workqueue for Overseer

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-11443:
---

Github user asfgit closed the pull request at:

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


> Remove the usage of workqueue for Overseer
> --
>
> Key: SOLR-11443
> URL: https://issues.apache.org/jira/browse/SOLR-11443
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
> Attachments: SOLR-11443.patch, SOLR-11443.patch, SOLR-11443.patch
>
>
> If we can remove the usage of workqueue, We can save a lot of IO blocking in 
> Overseer, hence boost performance a lot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11443) Remove the usage of workqueue for Overseer

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11443:


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

SOLR-11443: Remove the usage of workqueue for Overseer


> Remove the usage of workqueue for Overseer
> --
>
> Key: SOLR-11443
> URL: https://issues.apache.org/jira/browse/SOLR-11443
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
> Attachments: SOLR-11443.patch, SOLR-11443.patch, SOLR-11443.patch
>
>
> If we can remove the usage of workqueue, We can save a lot of IO blocking in 
> Overseer, hence boost performance a lot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-10335) Upgrade to Tika 1.16 when available

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved SOLR-10335.
--
Resolution: Fixed

Backported to 7x, 7_1 and 6_6 branches.

Thanks Tim!

> Upgrade to Tika 1.16 when available
> ---
>
> Key: SOLR-10335
> URL: https://issues.apache.org/jira/browse/SOLR-10335
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tim Allison
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Fix For: 7.1, 6.6.2
>
>
> Once POI 3.16-beta3 is out (early/mid April?), we'll push for a release of 
> Tika 1.15.
> Please let us know if you have any requests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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