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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=15273, name=jetty-launcher-3490-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
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=15284, name=jetty-launcher-3490-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
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.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=15273, name=jetty-launcher-3490-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
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.forPa

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

[Policeman Jenkins Server]

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

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

Error Message:
Timeout occured while waiting response from server at: http://127.0.0.1:39997/jx

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:39997/jx
at 
__randomizedtesting.SeedInfo.seed([9D385969D988EB2:8187BA4C3364E34A]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
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:1096)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:183)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:200)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:315)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991)
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.carr

[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk-9) - Build # 284 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/284/
Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 
--illegal-access=deny

All tests passed

Build Log:
[...truncated 1725 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/core/test/temp/junit4-J1-20171104_044436_0114516974598249441358.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 3 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/core/test/temp/junit4-J0-20171104_044436_01116518693262977043099.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 291 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/test-framework/test/temp/junit4-J0-20171104_045227_91011762996369532629571.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/test-framework/test/temp/junit4-J1-20171104_045227_9103179321033017617796.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 1054 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/analysis/common/test/temp/junit4-J0-20171104_045329_29811867037055905352080.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/analysis/common/test/temp/junit4-J1-20171104_045329_298517437944293550186.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 224 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/analysis/icu/test/temp/junit4-J1-20171104_045520_5108903984001022402571.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 5 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/analysis/icu/test/temp/junit4-J0-20171104_045520_510870668900095834072.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 249 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/analysis/kuromoji/test/temp/junit4-J0-20171104_045529_34614479432322351734412.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/analysis/kuromoji/test/temp/junit4-J1-20171104_045529_3467946572353130409930.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 154 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20821/
Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 
--illegal-access=deny

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.search.join.BlockJoinFacetDistribTest

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

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:32837/solr: create the collection time out:180s
at __randomizedtesting.SeedInfo.seed([B20B3158D75E93D2]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
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:1096)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:183)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:200)
at 
org.apache.solr.search.join.BlockJoinFacetDistribTest.setupCluster(BlockJoinFacetDistribTest.java:69)
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$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 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
org.apache.lucene.search.similarities.TestBasicModelIn.testRandomScoring

Error Message:
score(9.3639667E8,88)=2.99552179E9 < score(9.3639667E8,89)=2.99552205E9

Stack Trace:
java.lang.AssertionError: score(9.3639667E8,88)=2.99552179E9 < 
score(9.3639667E8,89)=2.99552205E9
at 
__randomizedtesting.SeedInfo.seed([F4D6FC34824F61D9:7F49A586983887D3]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.lucene.search.similarities.BaseSimilarityTestCase.doTestScoring(BaseSimilarityTestCase.java:423)
at 
org.apache.lucene.search.similarities.BaseSimilarityTestCase.testRandomScoring(BaseSimilarityTestCase.java:355)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  

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

[Policeman Jenkins Server]

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

48 tests failed.
FAILED:  org.apache.solr.backcompat.TestLuceneIndexBackCompat.testOldIndexes

Error Message:
invalid API spec: apispec/cores.Status.json

Stack Trace:
java.lang.RuntimeException: invalid API spec: apispec/cores.Status.json
at 
__randomizedtesting.SeedInfo.seed([D9172FF6D074688B:FECD6DA09799FD3C]:0)
at 
org.apache.solr.common.util.ValidatingJsonMap.parse(ValidatingJsonMap.java:318)
at org.apache.solr.common.util.Utils.lambda$getSpec$0(Utils.java:394)
at org.apache.solr.api.Api.getSpec(Api.java:65)
at org.apache.solr.api.ApiBag.register(ApiBag.java:73)
at org.apache.solr.core.PluginBag.put(PluginBag.java:217)
at org.apache.solr.core.PluginBag.put(PluginBag.java:188)
at 
org.apache.solr.core.CoreContainer.createHandler(CoreContainer.java:1540)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:535)
at org.apache.solr.util.TestHarness.(TestHarness.java:178)
at org.apache.solr.util.TestHarness.(TestHarness.java:141)
at org.apache.solr.util.TestHarness.(TestHarness.java:147)
at org.apache.solr.util.TestHarness.(TestHarness.java:110)
at 
org.apache.solr.backcompat.TestLuceneIndexBackCompat.setupCore(TestLuceneIndexBackCompat.java:93)
at 
org.apache.solr.backcompat.TestLuceneIndexBackCompat.testOldIndexes(TestLuceneIndexBackCompat.java:50)
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(TestRuleA

[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 71 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 28022 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/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.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (24.0 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.2.0-src.tgz...
   [smoker] 31.2 MB in 0.09 sec (359.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.2.0.tgz...
   [smoker] 71.0 MB in 0.20 sec (351.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.2.0.zip...
   [smoker] 81.4 MB in 0.24 sec (339.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.2.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.2.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.2.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 (287.7 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.2.0-src.tgz...
   [smoker] 53.0 MB in 0.15 sec (347.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.2.0.tgz...
   [smoker] 146.0 MB in 0.44 sec (333.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.2.0.zip...
   [smoker] 147.0 MB in 0.43 sec (341.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.2.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.2.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.2.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.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.2.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.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.2.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.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.2.0-java8
   [smoker] Creating Solr home directory 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.2.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 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]   [|]   [/]   [-]   [\]  

[jira] [Updated] (SOLR-11542) Add URP to route time partitioned collections

[David Smiley (JIRA)]

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

David Smiley updated SOLR-11542:

Attachment: SOLR_11542_time_series_URP.patch

New patch:
* Ensured URPs prior to DURP do not get re-run at this alias/collections level 
distributed phase.  Note: I ought to test that this actually works as expected 
...
* Throw helpful error if somehow the alias doesn't exist anymore yet we receive 
an indexing request.  (dubious situation).  But note it can still distribute 
requests if the alias exists but simply doesn't include the collection 
receiving the update any longer.
* Cache the parsing of the timestamps. Will re-parse if the Alias instance is 
modified.
* Added tests for time parsing
* Added tests to try different approaches on batch vs separate and which 
collection to send the request to, and commitWithin.

Still dependent on SOLR-11487 (metadata). And still want to test more, namely 
with TolerantUpdateProcessor.

> Add URP to route time partitioned collections
> -
>
> Key: SOLR-11542
> URL: https://issues.apache.org/jira/browse/SOLR-11542
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR_11542_time_series_URP.patch, 
> SOLR_11542_time_series_URP.patch
>
>
> Assuming we have some time partitioning metadata on an alias (see SOLR-11487 
> for the metadata facility), we'll then need to route documents to the right 
> collection.  I propose a new URP.  _(edit: originally it was thought 
> DistributedURP would be modified but thankfully we can avoid that)._
> The scope of this issue is:
> * decide on some alias metadata names & semantics
> * decide the collection suffix pattern.  Read/write code (needed to route).
> * the routing code
> No new partition creation nor deletion happens is this 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

[JENKINS] Lucene-Solr-Tests-7.x - Build # 217 - Failure

[Apache Jenkins Server]

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

All tests passed

Build Log:
[...truncated 602 lines...]
   [junit4] JVM J1: stdout was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/build/core/test/temp/junit4-J1-20171104_034814_7084394682251702877109.sysout
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] #
   [junit4] # There is insufficient memory for the Java Runtime Environment to 
continue.
   [junit4] # Native memory allocation (mmap) failed to map 524288 bytes for 
committing reserved memory.
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/build/core/test/J1/hs_err_pid5316.log
   [junit4] <<< JVM J1: EOF 

   [junit4] JVM J1: stderr was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/build/core/test/temp/junit4-J1-20171104_034814_7087679337457712129163.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: INFO: 
os::commit_memory(0xefa0, 524288, 0) failed; error='Cannot allocate 
memory' (errno=12)
   [junit4] <<< JVM J1: EOF 

[...truncated 978 lines...]
   [junit4] ERROR: JVM J1 ended with an exception, command line: 
/usr/local/asfpackages/java/jdk1.8.0_144/jre/bin/java 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/heapdumps
 -ea -esa -Dtests.prefix=tests -Dtests.seed=F65971480BB36080 -Xmx512M 
-Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false 
-Dtests.codec=random -Dtests.postingsformat=random 
-Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random 
-Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz 
-Dtests.luceneMatchVersion=7.2.0 -Dtests.cleanthreads=perMethod 
-Djava.util.logging.config.file=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false 
-Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=2 -DtempDir=./temp 
-Djava.io.tmpdir=./temp 
-Djunit4.tempDir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/build/core/test/temp
 -Dcommon.dir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene 
-Dclover.db.dir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/build/clover/db
 
-Djava.security.policy=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/tools/junit4/tests.policy
 -Dtests.LUCENE_VERSION=7.2.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
-Dtests.src.home=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x 
-Djava.security.egd=file:/dev/./urandom 
-Djunit4.childvm.cwd=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/build/core/test/J1
 -Djunit4.childvm.id=1 -Djunit4.childvm.count=3 -Dtests.leaveTemporary=false 
-Dtests.filterstacks=true 
-Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Dfile.encoding=US-ASCII -classpath 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/build/codecs/classes/java:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/build/test-framework/classes/java:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/test-framework/lib/junit-4.10.jar:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/test-framework/lib/randomizedtesting-runner-2.5.3.jar:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/build/core/classes/java:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/build/core/classes/test:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-launcher.jar:/x1/jenkins/.ant/lib/ivy-2.4.0.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-junit.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-apache-log4j.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-junit4.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-jai.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-javamail.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-apache-bsf.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-commons-net.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-antlr.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-jsch.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-apache-oro.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-commons-logging.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-netrexx.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-testutil.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-jdepend.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-apache-bcel.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-apache-xalan2.jar:/home/jenki

[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-9.0.1) - Build # 285 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/285/
Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 
--illegal-access=deny

8 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.index.TestBackwardsCompatibility

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_3DDCB2FC3A3414A2-001\3.0.1-cfs-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_3DDCB2FC3A3414A2-001\3.0.1-cfs-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_3DDCB2FC3A3414A2-001\3.0.1-cfs-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_3DDCB2FC3A3414A2-001\3.0.1-cfs-001

at __randomizedtesting.SeedInfo.seed([3DDCB2FC3A3414A2]: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.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
junit.framework.TestSuite.org.apache.lucene.codecs.blockterms.TestVarGapFixedIntervalPostingsFormat

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestVarGapFixedIntervalPostingsFormat_4258A078EDC61DBC-001\justSoYouGetSomeChannelErrors-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestVarGapFixedIntervalPostingsFormat_4258A078EDC61DBC-001\justSoYouGetSomeChannelErrors-001

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestVarGapFixedIntervalPostingsFormat_4258A078EDC61DBC-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestVarGapFixedIntervalPostingsFormat_4258A078EDC61DBC-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestVarGapFixedIntervalPostingsFormat_4258A078EDC61DBC-001\justSoYouGetSomeChannelErrors-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestVarGapFixedIntervalPostingsFormat_4258A078EDC61DBC-001\justSoYouGetSomeChannelErrors-001
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestVarGapFixedIntervalPostingsFormat_4258A078EDC61DBC-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestVarGapFixedIntervalPostingsFormat_4258A078EDC61DBC-001

at __randomizedtesting.SeedInfo.seed([4258A078EDC61DBC]: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(Statement

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/738/
Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseParallelGC 
--illegal-access=deny

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

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

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:42537/solr: create the collection time out:180s
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
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:1096)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:183)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:200)
at org.apache.solr.cloud.RecoveryZkTest.test(RecoveryZkTest.java:68)
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)
 

[JENKINS] Lucene-Solr-Tests-master - Build # 2152 - Still Failing

[Apache Jenkins Server]

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

All tests passed

Build Log:
[...truncated 496 lines...]
   [junit4] JVM J2: stdout was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/temp/junit4-J2-20171104_023000_9627787377306762851974.sysout
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] #
   [junit4] # There is insufficient memory for the Java Runtime Environment to 
continue.
   [junit4] # Native memory allocation (mmap) failed to map 7864320 bytes for 
committing reserved memory.
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/J2/hs_err_pid22361.log
   [junit4] <<< JVM J2: EOF 

   [junit4] JVM J2: stderr was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/temp/junit4-J2-20171104_023000_9624548914067358154756.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: INFO: 
os::commit_memory(0xff88, 7864320, 0) failed; error='Cannot 
allocate memory' (errno=12)
   [junit4] <<< JVM J2: EOF 

[...truncated 1179 lines...]
   [junit4] ERROR: JVM J2 ended with an exception, command line: 
/usr/local/asfpackages/java/jdk1.8.0_144/jre/bin/java 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/heapdumps
 -ea -esa -Dtests.prefix=tests -Dtests.seed=90523973A94328F9 -Xmx512M 
-Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false 
-Dtests.codec=random -Dtests.postingsformat=random 
-Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random 
-Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz 
-Dtests.luceneMatchVersion=8.0.0 -Dtests.cleanthreads=perMethod 
-Djava.util.logging.config.file=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false 
-Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=2 -DtempDir=./temp 
-Djava.io.tmpdir=./temp 
-Djunit4.tempDir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/temp
 
-Dcommon.dir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene
 
-Dclover.db.dir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/clover/db
 
-Djava.security.policy=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/tools/junit4/tests.policy
 -Dtests.LUCENE_VERSION=8.0.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
-Dtests.src.home=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master 
-Djava.security.egd=file:/dev/./urandom 
-Djunit4.childvm.cwd=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/J2
 -Djunit4.childvm.id=2 -Djunit4.childvm.count=3 -Dtests.leaveTemporary=false 
-Dtests.filterstacks=true 
-Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Dfile.encoding=UTF-8 -classpath 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/codecs/classes/java:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/test-framework/classes/java:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/test-framework/lib/junit-4.10.jar:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/test-framework/lib/randomizedtesting-runner-2.5.3.jar:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/classes/java:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/classes/test:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-launcher.jar:/x1/jenkins/.ant/lib/ivy-2.4.0.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-junit.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-apache-log4j.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-junit4.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-jai.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-javamail.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-apache-bsf.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-commons-net.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-antlr.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-jsch.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-apache-oro.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-commons-logging.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-netrexx.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-testutil.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-jdepend.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-apache-bcel.jar:/home/jenkins/tools/

[jira] [Resolved] (SOLR-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-11503.
---
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.2

> Collections created with legacyCloud=true cannot be opened if 
> legacyCloud=false
> ---
>
> Key: SOLR-11503
> URL: https://issues.apache.org/jira/browse/SOLR-11503
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6.1
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Critical
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11503.patch, SOLR-11503.patch, SOLR-11503.patch, 
> SOLR-11503.patch
>
>
> SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a 
> collection with legacyCloud=true then switch to legacyCloud=false, you get an 
> NPE because coreNodeName is not defined in core.properties.
> Since the default for legacyCloud changed from true to false between 6.6.1 
> and 7.x, this means that any attempt to upgrade Solr with existing 
> collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value 
> for legacyCloud is used in both. Collections created with 6.6.0 would work. 
> Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work.
> This is not as egregious with any collections *created with 7.0* since if the 
> default legacyCloud=false is present when the core is created, properties are 
> persisted with coreNodeName. However, if someone switches legacyCloud to 
> true, then creates a collection, then changes legacyCloud back to false then 
> they'll hit this even in 7.0+
> This happened because bit of reordering switched the order of the calls 
> below. coreNodeName is added to the descriptor in 
> create/createFromDescriptor(this, cd) via zkContgroller.preRegister so 
> coresLocator.create(this, cd) persists core.properties without coreNodeName.
> _original order_
> SolrCore core = createFromDescriptor(cd, true, newCollection);
> coresLocator.create(this, cd);
> (NOTE: private calls to create were renamed to createFromDescriptor in 
> SOLR-11122).
> I've got a fix in the works for creating cores, I'll attach a preliminary 
> patch w/o tests in a bit for discussion, but the question is really what to 
> do about 6.6.1 and 6.6.2 and 7.1 for that matter. 
> This is compounded by the fact that with the CVE, there's strong incentive to 
> move to 6.6.2. sgh.
> There are two parts to fixing this completely:
> 1> create core.properties correctly
> 2> deal with coreNodeName not being in the core.properties file by going to 
> ZK and getting it (and persisting it). Haven't worked that part out yet 
> though, not in the first patch. Note one point here if it works as I hope it 
> will update the core.properties files first time they're opened.
> Options that I see, there are really two parts:
> *part1 create the core.properties correctly*
> > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem.
> > Recommend people not install 7x over collections created with 6x until they 
> > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and 
> > creating collections is at your own risk.
> > Recommend that people change legacyCloud=true in 7.x until they start 
> > working with a fixed version, which one TBD.
> *part2 deal with coreNodeName not being in the core.properties*
> > Not backport and release with 7.2? set legacyCloud=true until then.
> > Backport to point releases like 7.1.1? 6.6.3?
> > and what about 7.0? I don't think many people will be affected by 7.0 since 
> > 7.1 came out so soon after. And setting legacyCloud=true will let people 
> > get by.
> Fixing the two parts is not a question, they both need to be fixed. The real 
> question is whether we need to create a point release that incorporates one 
> or both or whether saying "you must set legacyCloud=true prior to Solr 
> version 7.# in order to work with any collections created with Solr versions 
> 6.6.1 through 7.#".
> Let's hear opinions..



--
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-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11503:


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

SOLR-11503: Collections created with legacyCloud=true cannot be opened if 
legacyCloud=false

(cherry picked from commit d501ecd)


> Collections created with legacyCloud=true cannot be opened if 
> legacyCloud=false
> ---
>
> Key: SOLR-11503
> URL: https://issues.apache.org/jira/browse/SOLR-11503
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6.1
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Critical
> Attachments: SOLR-11503.patch, SOLR-11503.patch, SOLR-11503.patch, 
> SOLR-11503.patch
>
>
> SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a 
> collection with legacyCloud=true then switch to legacyCloud=false, you get an 
> NPE because coreNodeName is not defined in core.properties.
> Since the default for legacyCloud changed from true to false between 6.6.1 
> and 7.x, this means that any attempt to upgrade Solr with existing 
> collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value 
> for legacyCloud is used in both. Collections created with 6.6.0 would work. 
> Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work.
> This is not as egregious with any collections *created with 7.0* since if the 
> default legacyCloud=false is present when the core is created, properties are 
> persisted with coreNodeName. However, if someone switches legacyCloud to 
> true, then creates a collection, then changes legacyCloud back to false then 
> they'll hit this even in 7.0+
> This happened because bit of reordering switched the order of the calls 
> below. coreNodeName is added to the descriptor in 
> create/createFromDescriptor(this, cd) via zkContgroller.preRegister so 
> coresLocator.create(this, cd) persists core.properties without coreNodeName.
> _original order_
> SolrCore core = createFromDescriptor(cd, true, newCollection);
> coresLocator.create(this, cd);
> (NOTE: private calls to create were renamed to createFromDescriptor in 
> SOLR-11122).
> I've got a fix in the works for creating cores, I'll attach a preliminary 
> patch w/o tests in a bit for discussion, but the question is really what to 
> do about 6.6.1 and 6.6.2 and 7.1 for that matter. 
> This is compounded by the fact that with the CVE, there's strong incentive to 
> move to 6.6.2. sgh.
> There are two parts to fixing this completely:
> 1> create core.properties correctly
> 2> deal with coreNodeName not being in the core.properties file by going to 
> ZK and getting it (and persisting it). Haven't worked that part out yet 
> though, not in the first patch. Note one point here if it works as I hope it 
> will update the core.properties files first time they're opened.
> Options that I see, there are really two parts:
> *part1 create the core.properties correctly*
> > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem.
> > Recommend people not install 7x over collections created with 6x until they 
> > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and 
> > creating collections is at your own risk.
> > Recommend that people change legacyCloud=true in 7.x until they start 
> > working with a fixed version, which one TBD.
> *part2 deal with coreNodeName not being in the core.properties*
> > Not backport and release with 7.2? set legacyCloud=true until then.
> > Backport to point releases like 7.1.1? 6.6.3?
> > and what about 7.0? I don't think many people will be affected by 7.0 since 
> > 7.1 came out so soon after. And setting legacyCloud=true will let people 
> > get by.
> Fixing the two parts is not a question, they both need to be fixed. The real 
> question is whether we need to create a point release that incorporates one 
> or both or whether saying "you must set legacyCloud=true prior to Solr 
> version 7.# in order to work with any collections created with Solr versions 
> 6.6.1 through 7.#".
> Let's hear opinions..



--
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] [Updated] (SOLR-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-11503:
--
Attachment: SOLR-11503.patch

Final patch with CHANGES.txt

> Collections created with legacyCloud=true cannot be opened if 
> legacyCloud=false
> ---
>
> Key: SOLR-11503
> URL: https://issues.apache.org/jira/browse/SOLR-11503
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6.1
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Critical
> Attachments: SOLR-11503.patch, SOLR-11503.patch, SOLR-11503.patch, 
> SOLR-11503.patch
>
>
> SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a 
> collection with legacyCloud=true then switch to legacyCloud=false, you get an 
> NPE because coreNodeName is not defined in core.properties.
> Since the default for legacyCloud changed from true to false between 6.6.1 
> and 7.x, this means that any attempt to upgrade Solr with existing 
> collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value 
> for legacyCloud is used in both. Collections created with 6.6.0 would work. 
> Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work.
> This is not as egregious with any collections *created with 7.0* since if the 
> default legacyCloud=false is present when the core is created, properties are 
> persisted with coreNodeName. However, if someone switches legacyCloud to 
> true, then creates a collection, then changes legacyCloud back to false then 
> they'll hit this even in 7.0+
> This happened because bit of reordering switched the order of the calls 
> below. coreNodeName is added to the descriptor in 
> create/createFromDescriptor(this, cd) via zkContgroller.preRegister so 
> coresLocator.create(this, cd) persists core.properties without coreNodeName.
> _original order_
> SolrCore core = createFromDescriptor(cd, true, newCollection);
> coresLocator.create(this, cd);
> (NOTE: private calls to create were renamed to createFromDescriptor in 
> SOLR-11122).
> I've got a fix in the works for creating cores, I'll attach a preliminary 
> patch w/o tests in a bit for discussion, but the question is really what to 
> do about 6.6.1 and 6.6.2 and 7.1 for that matter. 
> This is compounded by the fact that with the CVE, there's strong incentive to 
> move to 6.6.2. sgh.
> There are two parts to fixing this completely:
> 1> create core.properties correctly
> 2> deal with coreNodeName not being in the core.properties file by going to 
> ZK and getting it (and persisting it). Haven't worked that part out yet 
> though, not in the first patch. Note one point here if it works as I hope it 
> will update the core.properties files first time they're opened.
> Options that I see, there are really two parts:
> *part1 create the core.properties correctly*
> > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem.
> > Recommend people not install 7x over collections created with 6x until they 
> > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and 
> > creating collections is at your own risk.
> > Recommend that people change legacyCloud=true in 7.x until they start 
> > working with a fixed version, which one TBD.
> *part2 deal with coreNodeName not being in the core.properties*
> > Not backport and release with 7.2? set legacyCloud=true until then.
> > Backport to point releases like 7.1.1? 6.6.3?
> > and what about 7.0? I don't think many people will be affected by 7.0 since 
> > 7.1 came out so soon after. And setting legacyCloud=true will let people 
> > get by.
> Fixing the two parts is not a question, they both need to be fixed. The real 
> question is whether we need to create a point release that incorporates one 
> or both or whether saying "you must set legacyCloud=true prior to Solr 
> version 7.# in order to work with any collections created with Solr versions 
> 6.6.1 through 7.#".
> Let's hear opinions..



--
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-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11503:


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

SOLR-11503: Collections created with legacyCloud=true cannot be opened if 
legacyCloud=false


> Collections created with legacyCloud=true cannot be opened if 
> legacyCloud=false
> ---
>
> Key: SOLR-11503
> URL: https://issues.apache.org/jira/browse/SOLR-11503
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6.1
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Critical
> Attachments: SOLR-11503.patch, SOLR-11503.patch, SOLR-11503.patch, 
> SOLR-11503.patch
>
>
> SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a 
> collection with legacyCloud=true then switch to legacyCloud=false, you get an 
> NPE because coreNodeName is not defined in core.properties.
> Since the default for legacyCloud changed from true to false between 6.6.1 
> and 7.x, this means that any attempt to upgrade Solr with existing 
> collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value 
> for legacyCloud is used in both. Collections created with 6.6.0 would work. 
> Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work.
> This is not as egregious with any collections *created with 7.0* since if the 
> default legacyCloud=false is present when the core is created, properties are 
> persisted with coreNodeName. However, if someone switches legacyCloud to 
> true, then creates a collection, then changes legacyCloud back to false then 
> they'll hit this even in 7.0+
> This happened because bit of reordering switched the order of the calls 
> below. coreNodeName is added to the descriptor in 
> create/createFromDescriptor(this, cd) via zkContgroller.preRegister so 
> coresLocator.create(this, cd) persists core.properties without coreNodeName.
> _original order_
> SolrCore core = createFromDescriptor(cd, true, newCollection);
> coresLocator.create(this, cd);
> (NOTE: private calls to create were renamed to createFromDescriptor in 
> SOLR-11122).
> I've got a fix in the works for creating cores, I'll attach a preliminary 
> patch w/o tests in a bit for discussion, but the question is really what to 
> do about 6.6.1 and 6.6.2 and 7.1 for that matter. 
> This is compounded by the fact that with the CVE, there's strong incentive to 
> move to 6.6.2. sgh.
> There are two parts to fixing this completely:
> 1> create core.properties correctly
> 2> deal with coreNodeName not being in the core.properties file by going to 
> ZK and getting it (and persisting it). Haven't worked that part out yet 
> though, not in the first patch. Note one point here if it works as I hope it 
> will update the core.properties files first time they're opened.
> Options that I see, there are really two parts:
> *part1 create the core.properties correctly*
> > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem.
> > Recommend people not install 7x over collections created with 6x until they 
> > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and 
> > creating collections is at your own risk.
> > Recommend that people change legacyCloud=true in 7.x until they start 
> > working with a fixed version, which one TBD.
> *part2 deal with coreNodeName not being in the core.properties*
> > Not backport and release with 7.2? set legacyCloud=true until then.
> > Backport to point releases like 7.1.1? 6.6.3?
> > and what about 7.0? I don't think many people will be affected by 7.0 since 
> > 7.1 came out so soon after. And setting legacyCloud=true will let people 
> > get by.
> Fixing the two parts is not a question, they both need to be fixed. The real 
> question is whether we need to create a point release that incorporates one 
> or both or whether saying "you must set legacyCloud=true prior to Solr 
> version 7.# in order to work with any collections created with Solr versions 
> 6.6.1 through 7.#".
> Let's hear opinions..



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

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.lucene.index.TestBinaryDocValuesUpdates.testTonsOfUpdates

Error Message:
_0_b.fnm in dir=NRTCachingDirectory(RAMDirectory@5ec5a16e 
lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@788f71cc; 
maxCacheMB=0.4541015625 maxMergeSizeMB=0.2314453125)

Stack Trace:
java.io.FileNotFoundException: _0_b.fnm in 
dir=NRTCachingDirectory(RAMDirectory@5ec5a16e 
lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@788f71cc; 
maxCacheMB=0.4541015625 maxMergeSizeMB=0.2314453125)
at 
__randomizedtesting.SeedInfo.seed([DDEAB6AAE9F81453:A5CF68A10BD83BB1]:0)
at 
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:750)
at 
org.apache.lucene.store.Directory.openChecksumInput(Directory.java:119)
at 
org.apache.lucene.store.MockDirectoryWrapper.openChecksumInput(MockDirectoryWrapper.java:1072)
at 
org.apache.lucene.codecs.lucene60.Lucene60FieldInfosFormat.read(Lucene60FieldInfosFormat.java:113)
at 
org.apache.lucene.index.SegmentReader.initFieldInfos(SegmentReader.java:190)
at org.apache.lucene.index.SegmentReader.(SegmentReader.java:93)
at 
org.apache.lucene.index.ReadersAndUpdates.writeFieldUpdates(ReadersAndUpdates.java:688)
at 
org.apache.lucene.index.IndexWriter$ReaderPool.writeSomeDocValuesUpdates(IndexWriter.java:703)
at 
org.apache.lucene.index.FrozenBufferedUpdates.apply(FrozenBufferedUpdates.java:331)
at 
org.apache.lucene.index.DocumentsWriter$ResolveUpdatesEvent.process(DocumentsWriter.java:723)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5057)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5045)
at 
org.apache.lucene.index.IndexWriter.updateDocValues(IndexWriter.java:1879)
at 
org.apache.lucene.index.TestBinaryDocValuesUpdates.testTonsOfUpdates(TestBinaryDocValuesUpdates.java:1323)
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.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 
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.Sta

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitStaticIndexReplication

Error Message:
We expected shard split to succeed on a static index but it didn't. Found state 
= running

Stack Trace:
java.lang.AssertionError: We expected shard split to succeed on a static index 
but it didn't. Found state = running
at 
__randomizedtesting.SeedInfo.seed([59F219ED8B56884B:13B88DED1AFEA74E]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitStaticIndexReplication(ShardSplitTest.java:223)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.index.TestBackwardsCompatibility

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\backward-codecs\test\J1\temp\lucene.index.TestBackwardsCompatibility_8EAC738A235C3CFA-001\4.0.0.2-nocfs-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\backward-codecs\test\J1\temp\lucene.index.TestBackwardsCompatibility_8EAC738A235C3CFA-001\4.0.0.2-nocfs-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\lucene\build\backward-codecs\test\J1\temp\lucene.index.TestBackwardsCompatibility_8EAC738A235C3CFA-001\4.0.0.2-nocfs-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\backward-codecs\test\J1\temp\lucene.index.TestBackwardsCompatibility_8EAC738A235C3CFA-001\4.0.0.2-nocfs-001

at __randomizedtesting.SeedInfo.seed([8EAC738A235C3CFA]: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:  junit.framework.TestSuite.org.apache.solr.SampleTest

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\J1\temp\solr.SampleTest_3A61E88FE69FA70-001\init-core-data-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.SampleTest_3A61E88FE69FA70-001\init-core-data-001

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.SampleTest_3A61E88FE69FA70-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.SampleTest_3A61E88FE69FA70-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\J1\temp\solr.SampleTest_3A61E88FE69FA70-001\init-core-data-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.SampleTest_3A61E88FE69FA70-001\init-core-data-001
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.SampleTest_3A61E88FE69FA70-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.SampleTest_3A61E88FE69FA70-001

at __randomizedtesting.SeedInfo.seed([3A61E88FE69FA70]: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.

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.LeaderElectionContextKeyTest

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

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:37217/solr: addreplica the collection time 
out:180s
at __randomizedtesting.SeedInfo.seed([3224E89EEFBBF04E]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
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:1096)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:183)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:200)
at 
org.apache.solr.cloud.LeaderElectionContextKeyTest.setupCluster(LeaderElectionContextKeyTest.java:60)
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:  
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=17888, name=jetty-launcher-2934-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
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.CuratorZookee

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.MoveReplicaHDFSTest.test

Error Message:
Could not load collection from ZK: movereplicatest_coll

Stack Trace:
org.apache.solr.common.SolrException: Could not load collection from ZK: 
movereplicatest_coll
at 
__randomizedtesting.SeedInfo.seed([806B0152ABB9E0F6:83F3E8805458D0E]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1172)
at 
org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:692)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:130)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:110)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:247)
at org.apache.solr.cloud.MoveReplicaTest.test(MoveReplicaTest.java:192)
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)
 

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

[Policeman Jenkins Server]

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

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

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth: 1) 
Thread[id=76, name=jetty-launcher-1-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: 1 thread leaked from SUITE 
scope at org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth: 
   1) Thread[id=76, name=jetty-launcher-1-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)
at __randomizedtesting.SeedInfo.seed([484D45852A7BCF2E]:0)




Build Log:
[...truncated 11479 lines...]
   [junit4] Suite: 
org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth
   [junit4]   2> Creating dataDir: 
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/solr/build/solr-core/test/J0/temp/solr.security.hadoop.TestImpersonationWithHadoopAuth_484D45852A7BCF2E-001/init-core-data-001
   [junit4]   2> 0INFO  
(SUITE-TestImpersonationWithHadoopAuth-seed#[484D45852A7BCF2E]-worker) [] 
o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=true
   [junit4]   2> 97   INFO  
(SUITE-TestImpersonationWithHadoopAuth-seed#[484D45852A7BCF2E]-worker) [] 
o.e.j.u.log Logging initialized @1976ms
   [junit4]   2> 105  INFO  
(SUITE-TestImpersonationWithHadoopAuth-seed#[484D45852A7BCF2E]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 120  INFO  
(SUITE-TestImpersonationWithHadoopAuth-seed#[484D45852

[jira] [Commented] (SOLR-11003) Enabling bi-directional CDCR on cluster for better failover

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11003:


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

SOLR-11003: Support bi-directional syncing of cdcr clusters. We still only 
support actively into one cluster cluster,
 but have the ability to switch indexing clusters and cdcr will replicate 
correctly


> Enabling bi-directional CDCR on cluster for better failover
> ---
>
> Key: SOLR-11003
> URL: https://issues.apache.org/jira/browse/SOLR-11003
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11003-tlogutils.patch, SOLR-11003.patch, 
> SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, 
> SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, 
> SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, 
> sample-configs.zip
>
>
> The latest version of Solr CDCR across collections / clusters is in 
> active-passive format, where we can index into source collection and the 
> updates gets forwarded to the passive one and vice-versa is not supported.
> https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html
> https://issues.apache.org/jira/browse/SOLR-6273
> We are try to get a  design ready to index in both collections and the 
> updates gets reflected across the collections in real-time (given the backlog 
> of replicating updates to other data center). ClusterACollectionA => 
> ClusterBCollectionB | ClusterBCollectionB => ClusterACollectionA.
> The STRONG RECOMMENDED way to keep indexing in ClusterACollectionA which 
> forwards the updates to ClusterBCollectionB. If ClusterACollectionA gets 
> down, we point the indexer and searcher application to ClusterBCollectionB. 
> Once ClusterACollectionA is up, depending on updates count, they will be 
> bootstrapped or forwarded to ClusterACollectionA from ClusterBCollectionB and 
> keep indexing on the ClusterBCollectionB.



--
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-11484) CloudSolrClient's cache of collection clusterstate can cause RouteExceptions when attempting directUpdates after collection modifications

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-11484:
---

There are two possibilities
1) the state.json had no leader
2) there is no leader at all

Most often it's because of #1. In case of #1 it's better to try a random node 
than fail fast

> CloudSolrClient's cache of collection clusterstate can cause RouteExceptions 
> when attempting directUpdates after collection modifications
> -
>
> Key: SOLR-11484
> URL: https://issues.apache.org/jira/browse/SOLR-11484
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11484.patch, SOLR-11484.patch, 
> jenkins.thetaphi.20662.txt
>
>
> This was discovered while auditing jenkins failures from 
> {{TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete}} 
> (where a test explicitly deletes and then recreates a collection with the 
> same name), but as noted in a comment below, SOLR-11392 is another example of 
> non-obvious test failures that can pop up because of this bug.
> In practice, it can affect any CloudSolrClient user after changes have been 
> made to a collection (to add/move replicas, etc...)
> 
> Original jira notes...
> {{TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete}}
> seems to fail with non-trivial frequency, so I grabbed the logs from a recent 
> failure and starting trying to follow along with the actions to figure out 
> what exactly is happening
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20662/
> {noformat}
>[junit4] ERROR   20.3s J1 | 
> TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete <<<
>[junit4]> Throwable #1: 
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
> server at https://127.0.0.1:42959/solr/testcollection_shard1_replica_n3: 
> Expected mime type a
> pplication/octet-stream but got text/html. 
>[junit4]> 
>[junit4]>  content="text/html;charset=ISO-8859-1"/>
>[junit4]> Error 404 
> {noformat}
> The crux of this failure appears to be a genuine bug in how CloudSolrClient 
> uses it's cached ClusterState info when doing (direct) updates.  The key bits 
> seem to be:
> * CloudSolrClient does _something_ (update,query,etc...) with a collection 
> causing the current cluster state for the collection to be cached
> * The actual collection changes such that a Solr node/core no longer exists 
> as part of the collection
> * CloudSolrClient is asked to process an UpdateRequest which triggers the 
> code paths for the {{directUpdate()}} method -- which attempts to route the 
> updates directly to a replica of the appropriate shard using the (cache) 
> collection state info
> * CloudSolrClient (may) attempt to send that UpdateRequest to a node/core 
> that doesn't exist, getting a 404 -- which does not (seem to) trigger a state 
> refresh, or retry to find a correct URL to resend the update to.
> Details to follow in comment



--
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-11484) CloudSolrClient's cache of collection clusterstate can cause RouteExceptions when attempting directUpdates after collection modifications

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-11484:


Hi [~varunthacker] - thanks for including me here.

bq. ... I guess the work "Only" in the flag would mean that the update should 
fail if there are no leaders? ...

Correct, that was the intention. For convenience 
[copy/pasting|https://issues.apache.org/jira/browse/SOLR-9512?focusedCommentId=15506019&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15506019]
 a SOLR-9512 comment here:

bq. The SOLR-9090 {{directUpdatesToLeadersOnly}} motivation/intention was for 
the flag to be not a hint but a directive and for updates to 'fail fast' if 
there is (temporarily or otherwise) no shard leader. Fail fast (and let the 
caller of the {{CloudSolrClient}} handle alarming and retries as it sees fit) 
as opposed to sending or retry-sending to a non-leader which would then forward 
to the leader (and potentially still fail eventually, 
eventually/not-fast-slowly).

As far as the

bq. ... In which case our tests should not set this flag and use the default 
behaviour ...

alternative is concerned, hmm, i'm not sure, wouldn't that reduce test coverage 
in general, though yes perhaps for very specific tests a test could opt-out of 
randomising the value of the flag.

ticket cross-reference: SOLR-11507 concerns flag randomisation in the test 
CloudSolrClient - [~dsmiley] and [~gerlowskija] any thoughts on this?

(I should also mention that the {{directUpdatesToLeadersOnly}} flag's addition 
predates the new replica types and I haven't yet considered if/how that might 
change the meaning of the flag.)

> CloudSolrClient's cache of collection clusterstate can cause RouteExceptions 
> when attempting directUpdates after collection modifications
> -
>
> Key: SOLR-11484
> URL: https://issues.apache.org/jira/browse/SOLR-11484
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11484.patch, SOLR-11484.patch, 
> jenkins.thetaphi.20662.txt
>
>
> This was discovered while auditing jenkins failures from 
> {{TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete}} 
> (where a test explicitly deletes and then recreates a collection with the 
> same name), but as noted in a comment below, SOLR-11392 is another example of 
> non-obvious test failures that can pop up because of this bug.
> In practice, it can affect any CloudSolrClient user after changes have been 
> made to a collection (to add/move replicas, etc...)
> 
> Original jira notes...
> {{TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete}}
> seems to fail with non-trivial frequency, so I grabbed the logs from a recent 
> failure and starting trying to follow along with the actions to figure out 
> what exactly is happening
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20662/
> {noformat}
>[junit4] ERROR   20.3s J1 | 
> TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete <<<
>[junit4]> Throwable #1: 
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
> server at https://127.0.0.1:42959/solr/testcollection_shard1_replica_n3: 
> Expected mime type a
> pplication/octet-stream but got text/html. 
>[junit4]> 
>[junit4]>  content="text/html;charset=ISO-8859-1"/>
>[junit4]> Error 404 
> {noformat}
> The crux of this failure appears to be a genuine bug in how CloudSolrClient 
> uses it's cached ClusterState info when doing (direct) updates.  The key bits 
> seem to be:
> * CloudSolrClient does _something_ (update,query,etc...) with a collection 
> causing the current cluster state for the collection to be cached
> * The actual collection changes such that a Solr node/core no longer exists 
> as part of the collection
> * CloudSolrClient is asked to process an UpdateRequest which triggers the 
> code paths for the {{directUpdate()}} method -- which attempts to route the 
> updates directly to a replica of the appropriate shard using the (cache) 
> collection state info
> * CloudSolrClient (may) attempt to send that UpdateRequest to a node/core 
> that doesn't exist, getting a 404 -- which does not (seem to) trigger a state 
> refresh, or retry to find a correct URL to resend the update to.
> Details to follow in comment



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

--

[jira] [Updated] (SOLR-11003) Enabling bi-directional CDCR on cluster for better failover

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-11003:
-
Attachment: SOLR-11003.patch

Made some changes to CdcrBidirectionalTest 

> Enabling bi-directional CDCR on cluster for better failover
> ---
>
> Key: SOLR-11003
> URL: https://issues.apache.org/jira/browse/SOLR-11003
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11003-tlogutils.patch, SOLR-11003.patch, 
> SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, 
> SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, 
> SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, 
> sample-configs.zip
>
>
> The latest version of Solr CDCR across collections / clusters is in 
> active-passive format, where we can index into source collection and the 
> updates gets forwarded to the passive one and vice-versa is not supported.
> https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html
> https://issues.apache.org/jira/browse/SOLR-6273
> We are try to get a  design ready to index in both collections and the 
> updates gets reflected across the collections in real-time (given the backlog 
> of replicating updates to other data center). ClusterACollectionA => 
> ClusterBCollectionB | ClusterBCollectionB => ClusterACollectionA.
> The STRONG RECOMMENDED way to keep indexing in ClusterACollectionA which 
> forwards the updates to ClusterBCollectionB. If ClusterACollectionA gets 
> down, we point the indexer and searcher application to ClusterBCollectionB. 
> Once ClusterACollectionA is up, depending on updates count, they will be 
> bootstrapped or forwarded to ClusterACollectionA from ClusterBCollectionB and 
> keep indexing on the ClusterBCollectionB.



--
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 (64bit/jdk1.8.0_144) - Build # 20819 - Still Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates

Error Message:
Error from server at http://127.0.0.1:44223/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:44223/solr: create the collection time out:180s
at __randomizedtesting.SeedInfo.seed([2AE4239E48FCD49A]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
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:1096)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:183)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:200)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.createMiniSolrCloudCluster(TestStressCloudBlindAtomicUpdates.java:132)
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)




Build Log:
[...truncated 13352 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates
   [junit4]   2> 2590780 INFO  
(SUITE-TestStressCloudBlindAtomicUpdates-seed#[2AE4239E48FCD49A]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.TestStressCloudBlindAtomicUpdates_2AE4239E48FCD49A-001/init-core-data-001
   [junit4]   2> 2590781 INFO  
(SUITE-TestStressCloudBlindAtomicUpdates-seed#[2AE4239E48FCD49A]-worker) [] 
o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=true
   [junit4]   2> 2590782 INFO  
(SUITE-TestStressCloudBlindAtomicUpdat

RE: JDK 10 b29 Early Access is available on jdk.java.net

[Uwe Schindler]

Hi,

 

In general, Java 10 preview build works correct. All Lucene tests work 
correctly.

 

But we have a problem with Mockito's Bytebuddy. The Mocking framework throws an 
Exception if it detects Java 10. I opened a bug report:

  
https://github.com/raphw/byte-buddy/issues/370

 

For now I disabled the Java 10 tests. I will add an assume to the Mockito-based 
tests, so they are disabled, if the Bytebuddy method throws an Exception (can 
be done by a simple check). I will take care tomorrow.

 

Rory, I will come back to you once I added an workaround for the usage of 
Mocking frameworks.

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: Rory O'Donnell [mailto:rory.odonn...@oracle.com] 
Sent: Friday, November 3, 2017 5:10 PM
To: dev@lucene.apache.org; Uwe Schindler ; 
dawid.we...@cs.put.poznan.pl
Cc: rory.odonn...@oracle.com; 'Dalibor Topic' ; 
'Balchandra Vaidya' ; 'Muneer Kolarkunnu' 

Subject: Re: JDK 10 b29 Early Access is available on jdk.java.net

 

Thanks Uwe, looking forward to your report !

Rgds,Rory

 

On 03/11/2017 15:23, Uwe Schindler wrote:

Hi Rory,

 

I just came back from J-Fall 2017. Thanks for the update about new EA builds! I 
was waiting for it, and now I can try it out, cool. I will report back soon, 
once I added JDK 10 to our Jenkins Cluster.

 

We are happy to see the new version numbering proposal that uses the usual 
major.minor pattern, counting from 10 onwards instead of the year-month style; 
Dalibor and I discussed about it on our train ride today! When testing the new 
builds, I hope this time nothing breaks because the main version number has 
suddenly 2 digits 😊.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de  

 

From: Rory O'Donnell [mailto:rory.odonn...@oracle.com] 
Sent: Friday, November 3, 2017 10:48 AM
To: dawid.we...@cs.put.poznan.pl  ; 
u...@thetaphi.de  
Cc: rory.odonn...@oracle.com  ; Dalibor Topic  
 ; Balchandra Vaidya 
  ; Muneer 
Kolarkunnu   ; 
dev@lucene.apache.org  
Subject: JDK 10 b29 Early Access is available on jdk.java.net

 

 


Hi Uwe & Dawid, 

JDK 10 Early Access  build 29 is available at : - jdk.java.net/10/

JDK 10 Early Access Release Notes are available [1]

JDK 10 Schedule, Status & Features are available [2]


Notes


*   OpenJDK EA binaries will be available at a later date.
*   Oracle has proposed: Newer version-string scheme for the Java SE 
Platform and the JDK 

*   Please see Mark Reinhold's proposal [3] , feedback via the mailing list 
to Mark please.

Feedback - If you have suggestions or encounter bugs, please submit them using 
the usual Java SE bug-reporting channel. 
Be sure to include complete version information from the output of the java 
--version command.

Regards,
Rory

[1] http://jdk.java.net/10/release-notes
[2] http://openjdk.java.net/projects/jdk/10/
[3] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/89.html




-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland 





-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland 

RE: [JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-10-ea+29) - Build # 20818 - Still Unstable!

[Uwe Schindler]

Hi,

In general, Java 10 preview build works correct. All Lucene tests fail. But we 
have a problem with Mockito's Bytebuddy. The Mocking framework throws an 
Exception if it detects Java 10. I opened a bug report:
https://github.com/raphw/byte-buddy/issues/370

For now I disabled the Java 10 tests. I will add an assume to the Mockito-based 
tests, so they are disabled, if the Bytebuddy method throws an Exception (can 
be done by a simple check). I will take care tomorrow.

Uwe

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

> -Original Message-
> From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
> Sent: Friday, November 3, 2017 8:42 PM
> To: dev@lucene.apache.org
> Subject: [JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-10-ea+29) - Build #
> 20818 - Still Unstable!
> Importance: Low
> 
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20818/
> Java: 64bit/jdk-10-ea+29 -XX:-UseCompressedOops -XX:+UseSerialGC --illegal-
> access=deny
> 
> 75 tests failed.
> FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.OverseerTest
> 
> Error Message:
> 29 threads leaked from SUITE scope at org.apache.solr.cloud.OverseerTest:
> 1) Thread[id=11717, name=TEST-OverseerTest.testDoubleAssignment-
> seed#[393EAB7FEDECCD7D]-SendThread(127.0.0.1:39907),
> state=TIMED_WAITING, group=TGRP-OverseerTest] at java.base@10-
> ea/java.lang.Thread.sleep(Native Method) at
> app//org.apache.zookeeper.ClientCnxnSocketNIO.cleanup(ClientCnxnSocket
> NIO.java:230) at
> app//org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.jav
> a:1246) at
> app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:11
> 70)2) Thread[id=11642, name=zkCallback-2892-thread-2,
> state=TIMED_WAITING, group=TGRP-OverseerTest] at java.base@10-
> ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@10-
> ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
> at java.base@10-
> ea/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Synchr
> onousQueue.java:462) at java.base@10-
> ea/java.util.concurrent.SynchronousQueue$TransferStack.transfer(Synchron
> ousQueue.java:361) at java.base@10-
> ea/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937
> ) at java.base@10-
> ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.jav
> a:1060) at java.base@10-
> ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
> java:1121) at java.base@10-
> ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecuto
> r.java:635) at java.base@10-ea/java.lang.Thread.run(Thread.java:844)
> 3) Thread[id=11628, name=Thread-2469-EventThread, state=WAITING,
> group=TGRP-OverseerTest] at java.base@10-
> ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@10-
> ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) 
> at
> java.base@10-
> ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.
> await(AbstractQueuedSynchronizer.java:2074) at java.base@10-
> ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java
> :435) at
> app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:50
> 1)4) Thread[id=11678, name=TEST-OverseerTest.testOverseerFailure-
> seed#[393EAB7FEDECCD7D]-SendThread(127.0.0.1:37473),
> state=TIMED_WAITING, group=TGRP-OverseerTest] at java.base@10-
> ea/java.lang.Thread.sleep(Native Method) at
> app//org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvide
> r.java:101) at
> app//org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnx
> n.java:997) at
> app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:10
> 60)5) Thread[id=11609, name=TEST-OverseerTest.testBadQueueItem-
> seed#[393EAB7FEDECCD7D]-EventThread, state=WAITING, group=TGRP-
> OverseerTest] at java.base@10-ea/jdk.internal.misc.Unsafe.park(Native
> Method) at java.base@10-
> ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) 
> at
> java.base@10-
> ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.
> await(AbstractQueuedSynchronizer.java:2074) at java.base@10-
> ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java
> :435) at
> app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:50
> 1)6) Thread[id=11590, name=TEST-OverseerTest.testReplay-
> seed#[393EAB7FEDECCD7D]-SendThread(127.0.0.1:33095),
> state=TIMED_WAITING, group=TGRP-OverseerTest] at java.base@10-
> ea/java.lang.Thread.sleep(Native Method) at
> app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:10
> 51)7) Thread[id=11718, name=TEST-OverseerTest.testDoubleAssignment-
> seed#[393EAB7FEDECCD7D]-EventT

[jira] [Updated] (SOLR-11250) Add new LTR model which loads the model definition from the external resource

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-11250:
---
Attachment: SOLR-11250.patch

Hello [~yuyano],

This week I finally managed to return to this ticket, sorry for the delay.

The attached patch is rebased against the latest master branch including the 
SOLR-11603 removal of the LTRScoringModel.hasParams() method. I've also 
tinkered a little with test code e.g. in TestWrapperModel the 
testOverwrittenMethods and testDelegateMethods are now linked to ensure good 
coverage if new methods are added in future and there are small 
TestWrapperModel.createMockWrappedModel and 
TestModelManagerPersistence.doWrapperModelPersistenceChecks helper methods 
factored out to reduce code duplication.

There's also two functional changes I'd value your opinion on:

* In the TestWrapperModel class the WrapperModel equals and hashCode methods 
previously had been excluded from the "this method must be overridden" check 
but I struggled to justify that exclusion to myself and so added overridden 
WrapperModel equals and hashCode methods. What do you think? We could go back 
to "not overridden" and add the reason (which i could not find) re: why the 
methods must not be overridden.

* Again in the TestWrapperModel class, the fact that the getName method was 
excluded from the "this method must be overridden" check caught my attention. 
The getName method being excluded from the check but the getFeatureStoreName 
method not being excluded. Following on from that I wondered, is there a use 
case where model name and/or feature store name could usefully be different 
between the wrapper model and the wrapped model?
** The wrapper model itself has no features and so requiring that the wrapper 
model and the wrapped model configure the same feature store name seems 
unproblematic from a technical perspective and might help avoid user error e.g. 
updating the wrapper model feature store name when the wrapped model feature 
store name should have been updated instead. What do you think?
** The wrapped model name being different from the wrapper model name, that is 
less clear-cut I think. The wrapped model could perhaps be called 
{{largeModelDefinition20171103}} and be stored in 
{{largeExternallyStoredModel.json}} file and the wrapper model could be called 
{{largeExternallyStoredModel}} and over time the 
{{largeExternallyStoredModel.json}} file content could change e.g. to a 
different {{largeModelDefinition20171206}} model name. On the other hand, 
having two different model names raises the question of which name is which and 
specifically which of the two names should be used in the {{rq=\{!ltr 
rerankModel=...}} parameter. For the purposes of the {{rq}} parameter the 
applicable model name is of course that of the wrapper model and the model name 
of the wrapped model is actually not of interest to anyone. What do you think?
** The revised patch validates that model name and feature store name match. 
This adds a little code complexity and also required small changes to the tests.

> Add new LTR model which loads the model definition from the external resource
> -
>
> Key: SOLR-11250
> URL: https://issues.apache.org/jira/browse/SOLR-11250
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Reporter: Yuki Yano
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11250.patch, SOLR-11250.patch, SOLR-11250.patch, 
> SOLR-11250_master.patch, SOLR-11250_master_v2.patch, 
> SOLR-11250_master_v3.patch, SOLR-11250_master_v4.patch
>
>
> We add new model which contains only the location of the external model and 
> loads it during the initialization.
> By this procedure, large models which are difficult to upload to ZooKeeper 
> can be available.
> The new model works as the wrapper of existing models, and deligates APIs to 
> them.
> We add two classes by this patch:
> * {{ExternalModel}} : a base class for models with external resources.
> * {{URIExternalModel}} : an implementation of {{ExternalModel}} which loads 
> the external model from specified URI (ex. file:, http:, etc.).
> For example, if you have a model on the local disk 
> "file:///var/models/myModel.json", the definition of {{URIExternalModel}} 
> will be like the following.
> {code}
> {
>   "class" : "org.apache.solr.ltr.model.URIExternalModel",
>   "name" : "myURIExternalModel",
>   "features" : [],
>   "params" : {
> "uri" : "file:///var/models/myModel.json"
>   }
> }
> {code}
> If you use LTR with {{model=myURIExternalModel}}, the model of 
> {{myModel.json}} will be used for scoring documents.



--
This message was sent

[JENKINS] Solr-Artifacts-7.x - Build # 77 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-Artifacts-7.x/77/

No tests ran.

Build Log:
[...truncated 15075 lines...]
  [javadoc] # There is insufficient memory for the Java Runtime Environment to 
continue.
  [javadoc] # Native memory allocation (mmap) failed to map 4194304 bytes for 
committing reserved memory.
  [javadoc] # An error report file with more information is saved as:
  [javadoc] # 
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-7.x/solr/hs_err_pid3048.log

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-7.x/solr/common-build.xml:282:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-7.x/solr/core/build.xml:50: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-7.x/solr/common-build.xml:304:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-7.x/lucene/common-build.xml:2206:
 Javadoc returned 1

Total time: 23 minutes 14 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[Fast Archiver] Compressed 346.03 MB of artifacts by 30.5% relative to #76
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Resolved] (SOLR-11603) contrib/ltr LTRScoringModel.hasParams() method is unused

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-11603.

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

> contrib/ltr LTRScoringModel.hasParams() method is unused
> 
>
> Key: SOLR-11603
> URL: https://issues.apache.org/jira/browse/SOLR-11603
> Project: Solr
>  Issue Type: Task
>  Components: contrib - LTR
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Fix For: 7.2, master (8.0)
>
>
> The method is unused and can't foresee use of it in custom classes. However, 
> the presence of the method complicates wrapping/delegating models such as in 
> SOLR-11250 - hence the motivation to just remove the unused method.



--
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-11603) contrib/ltr LTRScoringModel.hasParams() method is unused

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11603:


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

SOLR-11603: Remove unused (public) LTRScoringModel.hasParams() method.


> contrib/ltr LTRScoringModel.hasParams() method is unused
> 
>
> Key: SOLR-11603
> URL: https://issues.apache.org/jira/browse/SOLR-11603
> Project: Solr
>  Issue Type: Task
>  Components: contrib - LTR
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>
> The method is unused and can't foresee use of it in custom classes. However, 
> the presence of the method complicates wrapping/delegating models such as in 
> SOLR-11250 - hence the motivation to just remove the unused method.



--
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-Solaris (64bit/jdk1.8.0) - Build # 1510 - Still Unstable!

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.lucene.search.similarities.TestBasicModelG.testRandomScoring

Error Message:
score(1.0,3)=1.4E-44 < score(1.0,4)=1.5E-44

Stack Trace:
java.lang.AssertionError: score(1.0,3)=1.4E-44 < score(1.0,4)=1.5E-44
at 
__randomizedtesting.SeedInfo.seed([C4EB518D67B3204:87D1ECAACC0CD40E]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.lucene.search.similarities.BaseSimilarityTestCase.doTestScoring(BaseSimilarityTestCase.java:423)
at 
org.apache.lucene.search.similarities.BaseSimilarityTestCase.testRandomScoring(BaseSimilarityTestCase.java:355)
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.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 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


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

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=35816, name=jetty-launcher-5622-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQue

[jira] [Commented] (SOLR-11603) contrib/ltr LTRScoringModel.hasParams() method is unused

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11603:


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

SOLR-11603: Remove unused (public) LTRScoringModel.hasParams() method.


> contrib/ltr LTRScoringModel.hasParams() method is unused
> 
>
> Key: SOLR-11603
> URL: https://issues.apache.org/jira/browse/SOLR-11603
> Project: Solr
>  Issue Type: Task
>  Components: contrib - LTR
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>
> The method is unused and can't foresee use of it in custom classes. However, 
> the presence of the method complicates wrapping/delegating models such as in 
> SOLR-11250 - hence the motivation to just remove the unused method.



--
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-Tests-master - Build # 2151 - Failure

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.lucene.search.similarities.TestBasicModelIn.testRandomScoring

Error Message:
score(8.3170448E7,234)=5.8408699E16 < score(8.3170448E7,235)=5.8408703E16

Stack Trace:
java.lang.AssertionError: score(8.3170448E7,234)=5.8408699E16 < 
score(8.3170448E7,235)=5.8408703E16
at 
__randomizedtesting.SeedInfo.seed([CBBB2E4ED9D1B850:402477FCC3A65E5A]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.lucene.search.similarities.BaseSimilarityTestCase.doTestScoring(BaseSimilarityTestCase.java:423)
at 
org.apache.lucene.search.similarities.BaseSimilarityTestCase.testRandomScoring(BaseSimilarityTestCase.java:355)
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.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 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 494 lines...]
   [junit4] Suite: org.apache.lucene.search.similarities.TestBasicModelIn
   [junit4]   1> 5.8408699E16 = score(DFRSimilarity, doc=0, freq=8.3170448E7), 
computed from:
   [junit4]   1>   2.14748365E9 = boost
   [junit4]   1>   6.6623643E17 = NormalizationH1, computed from: 
   [junit4]   1> 8.3170448E7 = tf
   [junit4]   1> 1.25163994E9 = avgFieldLength
   [junit4]   1> 3.35544352E8 = len
   [junit4]   1>   6.6623643E17 = BasicModelIn, computed from: 
   [junit4]   1> 6.0

[jira] [Created] (SOLR-11603) contrib/ltr LTRScoringModel.hasParams() method is unused

[Christine Poerschke (JIRA)]

Christine Poerschke created SOLR-11603:
--

 Summary: contrib/ltr LTRScoringModel.hasParams() method is unused
 Key: SOLR-11603
 URL: https://issues.apache.org/jira/browse/SOLR-11603
 Project: Solr
  Issue Type: Task
  Components: contrib - LTR
Reporter: Christine Poerschke
Assignee: Christine Poerschke


The method is unused and can't foresee use of it in custom classes. However, 
the presence of the method complicates wrapping/delegating models such as in 
SOLR-11250 - hence the motivation to just remove the unused method.



--
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-11461) contrib/ltr to move away from 6.0.0

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-11461.

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

> contrib/ltr to move away from 6.0.0
> 
>
> Key: SOLR-11461
> URL: https://issues.apache.org/jira/browse/SOLR-11461
> Project: Solr
>  Issue Type: Sub-task
>  Components: contrib - LTR
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 7.2, master (8.0)
>
>
> This ticket is to change the three occurrences of 
> {{6.0.0}} in {{solr/contrib/ltr}} to 
> {{$\{tests.luceneMatchVersion:LATEST\}}}
>  including testing that all the tests still pass.



--
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] [Assigned] (SOLR-11461) contrib/ltr to move away from 6.0.0

[Christine Poerschke (JIRA)]

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

Christine Poerschke reassigned SOLR-11461:
--

Assignee: Christine Poerschke

> contrib/ltr to move away from 6.0.0
> 
>
> Key: SOLR-11461
> URL: https://issues.apache.org/jira/browse/SOLR-11461
> Project: Solr
>  Issue Type: Sub-task
>  Components: contrib - LTR
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 7.2, master (8.0)
>
>
> This ticket is to change the three occurrences of 
> {{6.0.0}} in {{solr/contrib/ltr}} to 
> {{$\{tests.luceneMatchVersion:LATEST\}}}
>  including testing that all the tests still pass.



--
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] [Updated] (SOLR-11597) Implement RankNet.

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-11597:
---
Component/s: contrib - LTR

> Implement RankNet.
> --
>
> Key: SOLR-11597
> URL: https://issues.apache.org/jira/browse/SOLR-11597
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Reporter: Michael A. Alcorn
>Priority: Normal
>
> Implement RankNet as described in [this 
> tutorial|https://github.com/airalcorn2/Solr-LTR].



--
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-10132) Support facet.matches to cull facets returned with a regex

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-10132.

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

Thanks Gus!

> Support facet.matches to cull facets returned with a regex
> --
>
> Key: SOLR-10132
> URL: https://issues.apache.org/jira/browse/SOLR-10132
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: faceting
>Affects Versions: 6.4.1
>Reporter: Gus Heck
>Assignee: Christine Poerschke
>Priority: Major
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-10132.patch, SOLR-10132.patch, SOLR-10132.patch, 
> SOLR-10132.patch, SOLR-10132.patch
>
>
> I recently ran into a case where I really wanted to only return the next 
> level of a hierarchical facet, and while I was able to do that with a 
> coordinated set of dynamic fields, it occurred to me that this would have 
> been much much easier if I could have simply used PathHierarchyTokenizer and 
> written
> &facet.matches="/my/current/prefix/[^/]+$"
> thereby limiting the returned facets to the next level down and not return 
> the  additional  N levels I didn't (yet) want to display (numbering in the 
> thousands near the top of the tree). I suspect there are other good use 
> cases, and the patch seemed relatively tractable.



--
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-11597) Implement RankNet.

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-11597:


Hello Michael, thank you for opening this ticket with a pull request!

I will add your tutorial and the icml_ranking.pdf paper to my reading list :-)

In the meantime, here's some quick thoughts from a quick look at the pull 
request:

* Great class-level javadocs. Let's also add the new class to the table in the 
Solr Reference Guide the source for which is now in the same git repo as the 
code i.e. 
https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/src/learning-to-rank.adoc

* Curiosity only at this point, not yet having read your tutorial or the paper:
{code}
"weights" : [
  "1,2,3\n4,5,6\n7,8,9\n10,11,12",
  "13,14,15,16\n17,18,19,20",
  "21,22"
]
{code}
representation versus (say)
{code}
"weights" : [
  [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ], [ 10, 11, 12 ] ],
  [ [ 13, 14, 15, 16 ], [ 17, 18, 19, 20 ] ],
  [ [ 21, 22 ] ]
]
{code}

* How about implementing/overriding the {{validate}} method? E.g. if for the 
non-linearity parameter someone mistypes "sigmoidt" instead of "sigmoid" then 
the validate method could right away through a model exception instead of the 
doNonlinearity method later on being a no-op which could be tricky to debug 
from a user's perspective.

* Something probably already on your todo list and/or something which others in 
the community might be interested in collaborating on: test coverage of some 
sort, possibly but not necessarily similar to the existing TestLinearModel and 
TestMultipleAdditiveTreesModel tests

* minor thing: I'm pretty sure the {{String.format("...", ...);}} in the 
explain method will be flagged up by the forbidden-apis checks in {{ant 
precommit}} pointing towards {{String.format(Locale.???, "...", ...)}} as the 
alternative. Related link: 
https://github.com/policeman-tools/forbidden-apis/blob/master/src/main/resources/de/thetaphi/forbiddenapis/signatures/jdk-unsafe-1.6.txt#L48

> Implement RankNet.
> --
>
> Key: SOLR-11597
> URL: https://issues.apache.org/jira/browse/SOLR-11597
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Reporter: Michael A. Alcorn
>Priority: Normal
>
> Implement RankNet as described in [this 
> tutorial|https://github.com/airalcorn2/Solr-LTR].



--
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-SmokeRelease-master - Build # 879 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/879/

No tests ran.

Build Log:
[...truncated 28006 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/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:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (17.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-8.0.0-src.tgz...
   [smoker] 29.8 MB in 0.42 sec (71.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.tgz...
   [smoker] 70.9 MB in 0.60 sec (117.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.zip...
   [smoker] 81.3 MB in 1.20 sec (67.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6188 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6188 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] 
   [smoker] command "export JAVA_HOME="/home/jenkins/tools/java/latest1.8" 
PATH="/home/jenkins/tools/java/latest1.8/bin:$PATH" 
JAVACMD="/home/jenkins/tools/java/latest1.8/bin/java"; ant validate" failed:
   [smoker] Buildfile: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-8.0.0/build.xml
   [smoker] 
   [smoker] common.compile-tools:
   [smoker] 
   [smoker] -check-git-state:
   [smoker] 
   [smoker] -git-cleanroot:
   [smoker] 
   [smoker] -copy-git-state:
   [smoker] 
   [smoker] git-autoclean:
   [smoker] 
   [smoker] ivy-availability-check:
   [smoker] [loadresource] Do not set property disallowed.ivy.jars.list as its 
length is 0.
   [smoker] 
   [smoker] -ivy-fail-disallowed-ivy-version:
   [smoker] 
   [smoker] ivy-fail:
   [smoker] 
   [smoker] ivy-configure:
   [smoker] [ivy:configure] :: Apache Ivy 2.4.0 - 20141213170938 :: 
http://ant.apache.org/ivy/ ::
   [smoker] [ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-8.0.0/top-level-ivy-settings.xml
   [smoker] 
   [smoker] resolve:
   [smoker] 
   [smoker] init:
   [smoker] 
   [smoker] compile-core:
   [smoker] [mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-8.0.0/build/tools/classes/java
   [smoker] [javac] Compiling 7 source files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-8.0.0/build/tools/classes/java
   [smoker]  [copy] Copying 1 file to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-8.0.0/build/tools/classes/java
   [smoker] 
   [smoker] compile-tools:
   [smoker] 
   [smoker] compile-tools:
   [smoker] 
   [smoker] common.compile-tools:
   [smoker] 
   [smoker] -check-git-state:
   [smoker] 
   [smoker] -git-cleanroot:
   [smoker] 
   [smoker] -copy-git-state:
   [smoker] 
   [smoker] git-autoclean:
   [smoker] 
   [smoker] ivy-availability-check:
   [smoker] [loadresource] Do not set property disallowed.ivy.jars.list as its 
length is 0.
   [smoker] 
   [smoker] -ivy-fail-disallowed-ivy-version:
   [smoker] 
   [smoker] ivy-fail:
   [smoker] 
   [smoker] ivy-configure:
   [smoker] [ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-8.0.0/top-level-ivy-settings.xml
   [smoker] 
   [smoker] resolve:
   [smoker] 
   [smoker] init:
   [smoker] 
   [smoker] compile-core:
   [smoker] 
   [smoker] compile-tools:
   [smoker] [mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease

[jira] [Updated] (LUCENE-8034) SpanNotWeight returns wrong results due to integer overflow

[Hari Menon (JIRA)]

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

Hari Menon updated LUCENE-8034:
---
Attachment: LUCENE-8034.patch

> SpanNotWeight returns wrong results due to integer overflow
> ---
>
> Key: LUCENE-8034
> URL: https://issues.apache.org/jira/browse/LUCENE-8034
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/query/scoring, core/search
>Reporter: Hari Menon
>Priority: Minor
>  Labels: newbie, patch
> Attachments: LUCENE-8034.patch
>
>
> In SpanNotQuery, there is an acceptance condition:
> {code:java}
> if (candidate.endPosition() + post <= excludeSpans.startPosition()) {
> return AcceptStatus.YES;
> }
> {code}
> This overflows in case `candidate.endPosition() + post > Integer.MAX_VALUE`. 
> I have a fix for this which I am working on. Basically I am flipping the add 
> to a subtract.



--
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-Linux (64bit/jdk1.8.0_144) - Build # 736 - Unstable!

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test

Error Message:
Timeout occured while waiting response from server at: http://127.0.0.1:38423

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:38423
at 
__randomizedtesting.SeedInfo.seed([FEEA6B598445A71F:76BE54832AB9CAE7]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
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:1096)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:183)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:200)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:315)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991)
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 

[jira] [Updated] (LUCENE-8034) SpanNotWeight returns wrong results due to integer overflow

[Hari Menon (JIRA)]

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

Hari Menon updated LUCENE-8034:
---
Description: 
In SpanNotQuery, there is an acceptance condition:
{code:java}
if (candidate.endPosition() + post <= excludeSpans.startPosition()) {
return AcceptStatus.YES;
}
{code}

This overflows in case `candidate.endPosition() + post > Integer.MAX_VALUE`. I 
have a fix for this which I am working on. Basically I am flipping the 
condition to do subtraction instead of add.

  was:
In SpanNotQuery, there is an acceptance condition:
{code:java}
if (candidate.endPosition() + post <= excludeSpans.startPosition()) {
return AcceptStatus.YES;
  }
{code}

This overflows in case candidate.endPosition() + post > Integer.MAX_VALUE. I 
have a fix for this which I am working on. Basically I am flipping the 
condition to do subtraction instead of add.


> SpanNotWeight returns wrong results due to integer overflow
> ---
>
> Key: LUCENE-8034
> URL: https://issues.apache.org/jira/browse/LUCENE-8034
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/query/scoring, core/search
>Reporter: Hari Menon
>Priority: Minor
>
> In SpanNotQuery, there is an acceptance condition:
> {code:java}
> if (candidate.endPosition() + post <= excludeSpans.startPosition()) {
> return AcceptStatus.YES;
> }
> {code}
> This overflows in case `candidate.endPosition() + post > Integer.MAX_VALUE`. 
> I have a fix for this which I am working on. Basically I am flipping the 
> condition to do subtraction instead of add.



--
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] [Updated] (LUCENE-8034) SpanNotWeight returns wrong results due to integer overflow

[Hari Menon (JIRA)]

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

Hari Menon updated LUCENE-8034:
---
Description: 
In SpanNotQuery, there is an acceptance condition:
{code:java}
if (candidate.endPosition() + post <= excludeSpans.startPosition()) {
return AcceptStatus.YES;
}
{code}

This overflows in case `candidate.endPosition() + post > Integer.MAX_VALUE`. I 
have a fix for this which I am working on. Basically I am flipping the add to a 
subtract.

  was:
In SpanNotQuery, there is an acceptance condition:
{code:java}
if (candidate.endPosition() + post <= excludeSpans.startPosition()) {
return AcceptStatus.YES;
}
{code}

This overflows in case `candidate.endPosition() + post > Integer.MAX_VALUE`. I 
have a fix for this which I am working on. Basically I am flipping the 
condition to do subtraction instead of add.


> SpanNotWeight returns wrong results due to integer overflow
> ---
>
> Key: LUCENE-8034
> URL: https://issues.apache.org/jira/browse/LUCENE-8034
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/query/scoring, core/search
>Reporter: Hari Menon
>Priority: Minor
>
> In SpanNotQuery, there is an acceptance condition:
> {code:java}
> if (candidate.endPosition() + post <= excludeSpans.startPosition()) {
> return AcceptStatus.YES;
> }
> {code}
> This overflows in case `candidate.endPosition() + post > Integer.MAX_VALUE`. 
> I have a fix for this which I am working on. Basically I am flipping the add 
> to a subtract.



--
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] (LUCENE-8034) SpanNotWeight returns wrong results due to integer overflow

[Hari Menon (JIRA)]

Hari Menon created LUCENE-8034:
--

 Summary: SpanNotWeight returns wrong results due to integer 
overflow
 Key: LUCENE-8034
 URL: https://issues.apache.org/jira/browse/LUCENE-8034
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/query/scoring, core/search
Reporter: Hari Menon
Priority: Minor


In SpanNotQuery, there is an acceptance condition:
{code:java}
if (candidate.endPosition() + post <= excludeSpans.startPosition()) {
return AcceptStatus.YES;
  }
{code}

This overflows in case candidate.endPosition() + post > Integer.MAX_VALUE. I 
have a fix for this which I am working on. Basically I am flipping the 
condition to do subtraction instead of add.



--
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] [Updated] (SOLR-11590) Synchronize ZK connect/disconnect handling

[Noble Paul (JIRA)]

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

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

> Synchronize ZK connect/disconnect handling
> --
>
> Key: SOLR-11590
> URL: https://issues.apache.org/jira/browse/SOLR-11590
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-11590.patch
>
>
> Here is a sequence of 2 disconnects and re-connects
> {code}
> 1. 2017-10-31T08:34:23.106-0700 Watcher 
> org.apache.solr.common.cloud.ConnectionManager@1579ca20 
> name:ZooKeeperConnection Watcher:host:port got event WatchedEvent 
> state:Disconnected type:None path:null path:null type:None
> 2. 2017-10-31T08:34:23.106-0700 zkClient has disconnected
> 3. 2017-10-31T08:34:23.107-0700 Watcher 
> org.apache.solr.common.cloud.ConnectionManager@1579ca20 
> name:ZooKeeperConnection Watcher:host:port got event WatchedEvent 
> state:SyncConnected type:None path:null path:null type:None
> {code}
> {code}
> 1. 2017-10-31T08:36:46.541-0700 Watcher 
> org.apache.solr.common.cloud.ConnectionManager@1579ca20 
> name:ZooKeeperConnection Watcher:host:port got event WatchedEvent 
> state:Disconnected type:None path:null path:null type:None
> 2. 2017-10-31T08:36:46.549-0700 Watcher 
> org.apache.solr.common.cloud.ConnectionManager@1579ca20 
> name:ZooKeeperConnection Watcher:host:port got event WatchedEvent 
> state:SyncConnected type:None path:null path:null type:None
> 2. 2017-10-31T08:36:46.563-0700 zkClient has disconnected
> {code}
> In the first disconnect the sequence is -  get disconnect watcher, execute 
> disconnect code, execute connect code
> In the second disconnect the sequence is - get disconnect watcher, execute 
> connect code, execute disconnect code
> In the second sequence of events, if the JVM has leader replicas then all 
> updates start failing with "Cannot talk to ZooKeeper - Updates are disabled." 
> . This starts happening exactly after 27 seconds ( zk client timeout is 30s , 
> 90% of 30 = 27 - when the code thinks the session is likely expired). No 
> leadership changes since there was no session expiry. Unless you restart the 
> node all updates to the system continue to fail.
> These log lines correspond are from Solr 5.3 hence where the WatchedEvent was 
> still being logged as INFO
> We process the connect code and then process the disconnect code out of order 
> based on the log ordering. The connection is active but the flag is not set 
> and hence after 27 seconds {{zkCheck}} starts complaining that the connection 
> is likely expired
> A related Jira is SOLR-5721
> ZK gives us ordered watch events ( 
> https://zookeeper.apache.org/doc/r3.4.8/zookeeperProgrammers.html#sc_WatchGuarantees
>  ) but from what I understand Solr can still process them out of order. We 
> could take a lock and synchronize {{ConnectionManager#connected}} and 
> {{ConnectionManager#disconnected}} . 
> Would that be the right approach to take?



--
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] [Updated] (SOLR-11590) Synchronize ZK connect/disconnect handling

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-11590:
--
Attachment: (was: SOLR-11590.patch)

> Synchronize ZK connect/disconnect handling
> --
>
> Key: SOLR-11590
> URL: https://issues.apache.org/jira/browse/SOLR-11590
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-11590.patch
>
>
> Here is a sequence of 2 disconnects and re-connects
> {code}
> 1. 2017-10-31T08:34:23.106-0700 Watcher 
> org.apache.solr.common.cloud.ConnectionManager@1579ca20 
> name:ZooKeeperConnection Watcher:host:port got event WatchedEvent 
> state:Disconnected type:None path:null path:null type:None
> 2. 2017-10-31T08:34:23.106-0700 zkClient has disconnected
> 3. 2017-10-31T08:34:23.107-0700 Watcher 
> org.apache.solr.common.cloud.ConnectionManager@1579ca20 
> name:ZooKeeperConnection Watcher:host:port got event WatchedEvent 
> state:SyncConnected type:None path:null path:null type:None
> {code}
> {code}
> 1. 2017-10-31T08:36:46.541-0700 Watcher 
> org.apache.solr.common.cloud.ConnectionManager@1579ca20 
> name:ZooKeeperConnection Watcher:host:port got event WatchedEvent 
> state:Disconnected type:None path:null path:null type:None
> 2. 2017-10-31T08:36:46.549-0700 Watcher 
> org.apache.solr.common.cloud.ConnectionManager@1579ca20 
> name:ZooKeeperConnection Watcher:host:port got event WatchedEvent 
> state:SyncConnected type:None path:null path:null type:None
> 2. 2017-10-31T08:36:46.563-0700 zkClient has disconnected
> {code}
> In the first disconnect the sequence is -  get disconnect watcher, execute 
> disconnect code, execute connect code
> In the second disconnect the sequence is - get disconnect watcher, execute 
> connect code, execute disconnect code
> In the second sequence of events, if the JVM has leader replicas then all 
> updates start failing with "Cannot talk to ZooKeeper - Updates are disabled." 
> . This starts happening exactly after 27 seconds ( zk client timeout is 30s , 
> 90% of 30 = 27 - when the code thinks the session is likely expired). No 
> leadership changes since there was no session expiry. Unless you restart the 
> node all updates to the system continue to fail.
> These log lines correspond are from Solr 5.3 hence where the WatchedEvent was 
> still being logged as INFO
> We process the connect code and then process the disconnect code out of order 
> based on the log ordering. The connection is active but the flag is not set 
> and hence after 27 seconds {{zkCheck}} starts complaining that the connection 
> is likely expired
> A related Jira is SOLR-5721
> ZK gives us ordered watch events ( 
> https://zookeeper.apache.org/doc/r3.4.8/zookeeperProgrammers.html#sc_WatchGuarantees
>  ) but from what I understand Solr can still process them out of order. We 
> could take a lock and synchronize {{ConnectionManager#connected}} and 
> {{ConnectionManager#disconnected}} . 
> Would that be the right approach to take?



--
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-MacOSX (64bit/jdk1.8.0) - Build # 283 - Unstable!

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.core.TestLazyCores.testNoCommit

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([65005BE172611100:BA60FA30B94672A5]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:885)
at org.apache.solr.core.TestLazyCores.check10(TestLazyCores.java:847)
at 
org.apache.solr.core.TestLazyCores.testNoCommit(TestLazyCores.java:829)
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='10']
xml response was: 

00*:*


request was:q=*:*
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
... 41 more


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

[jira] [Commented] (SOLR-11590) Synchronize ZK connect/disconnect handling

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-11590:
---

LGTM

> Synchronize ZK connect/disconnect handling
> --
>
> Key: SOLR-11590
> URL: https://issues.apache.org/jira/browse/SOLR-11590
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-11590.patch
>
>
> Here is a sequence of 2 disconnects and re-connects
> {code}
> 1. 2017-10-31T08:34:23.106-0700 Watcher 
> org.apache.solr.common.cloud.ConnectionManager@1579ca20 
> name:ZooKeeperConnection Watcher:host:port got event WatchedEvent 
> state:Disconnected type:None path:null path:null type:None
> 2. 2017-10-31T08:34:23.106-0700 zkClient has disconnected
> 3. 2017-10-31T08:34:23.107-0700 Watcher 
> org.apache.solr.common.cloud.ConnectionManager@1579ca20 
> name:ZooKeeperConnection Watcher:host:port got event WatchedEvent 
> state:SyncConnected type:None path:null path:null type:None
> {code}
> {code}
> 1. 2017-10-31T08:36:46.541-0700 Watcher 
> org.apache.solr.common.cloud.ConnectionManager@1579ca20 
> name:ZooKeeperConnection Watcher:host:port got event WatchedEvent 
> state:Disconnected type:None path:null path:null type:None
> 2. 2017-10-31T08:36:46.549-0700 Watcher 
> org.apache.solr.common.cloud.ConnectionManager@1579ca20 
> name:ZooKeeperConnection Watcher:host:port got event WatchedEvent 
> state:SyncConnected type:None path:null path:null type:None
> 2. 2017-10-31T08:36:46.563-0700 zkClient has disconnected
> {code}
> In the first disconnect the sequence is -  get disconnect watcher, execute 
> disconnect code, execute connect code
> In the second disconnect the sequence is - get disconnect watcher, execute 
> connect code, execute disconnect code
> In the second sequence of events, if the JVM has leader replicas then all 
> updates start failing with "Cannot talk to ZooKeeper - Updates are disabled." 
> . This starts happening exactly after 27 seconds ( zk client timeout is 30s , 
> 90% of 30 = 27 - when the code thinks the session is likely expired). No 
> leadership changes since there was no session expiry. Unless you restart the 
> node all updates to the system continue to fail.
> These log lines correspond are from Solr 5.3 hence where the WatchedEvent was 
> still being logged as INFO
> We process the connect code and then process the disconnect code out of order 
> based on the log ordering. The connection is active but the flag is not set 
> and hence after 27 seconds {{zkCheck}} starts complaining that the connection 
> is likely expired
> A related Jira is SOLR-5721
> ZK gives us ordered watch events ( 
> https://zookeeper.apache.org/doc/r3.4.8/zookeeperProgrammers.html#sc_WatchGuarantees
>  ) but from what I understand Solr can still process them out of order. We 
> could take a lock and synchronize {{ConnectionManager#connected}} and 
> {{ConnectionManager#disconnected}} . 
> Would that be the right approach to take?



--
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] [Updated] (SOLR-11602) Add Markov Chain Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11602:
--
Description: 
Now that Streaming Expressions supports Monte Carlo simulations it would be 
useful to add Markov Chain support 
(https://en.wikipedia.org/wiki/Markov_chain). This ticket will add support for 
Markov Chain simulations.

Here is the syntax:

{code}

let(state0=array(.3, .4, .3),
state1=array(.2, .1, .7),
state2=array(.6, .2, .2),
states=matrix(state0, state1, state2),
m=markovChain(states, 0),
s=sample(m, 500))
{code}

The Markov chain is initialized with a matrix who's rows represent the 
different *states* of the system. The columns represent the probabilities of 
changing from one state to another state.

For example if we are in state 1 represented by the array(.2,.1,.7), there is a 
.7 percent probability that it will transition to state 2.






  was:
Now that Streaming Expressions supports Monte Carlo simulations it would be 
useful to also support Markov Chains 
(https://en.wikipedia.org/wiki/Markov_chain). This ticket will add support for 
Markov Chain simulations.

Here is the syntax:

{code}

let(state0=array(.3, .4, .3),
state1=array(.2, .1, .7),
state2=array(.6, .2, .2),
states=matrix(state0, state1, state2),
m=markovChain(states, 0),
s=sample(m, 500))
{code}

The Markov chain is initialized with a matrix who's rows represent the 
different *states* of the system. The columns represent the probabilities of 
changing from one state to another state.

For example if we are in state 1 represented by the array(.2,.1,.7), there is a 
.7 percent probability that it will transition to state 2.







> Add Markov Chain Stream Evaluator
> -
>
> Key: SOLR-11602
> URL: https://issues.apache.org/jira/browse/SOLR-11602
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11602.patch, SOLR-11602.patch, SOLR-11602.patch
>
>
> Now that Streaming Expressions supports Monte Carlo simulations it would be 
> useful to add Markov Chain support 
> (https://en.wikipedia.org/wiki/Markov_chain). This ticket will add support 
> for Markov Chain simulations.
> Here is the syntax:
> {code}
> let(state0=array(.3, .4, .3),
> state1=array(.2, .1, .7),
> state2=array(.6, .2, .2),
> states=matrix(state0, state1, state2),
> m=markovChain(states, 0),
> s=sample(m, 500))
> {code}
> The Markov chain is initialized with a matrix who's rows represent the 
> different *states* of the system. The columns represent the probabilities of 
> changing from one state to another state.
> For example if we are in state 1 represented by the array(.2,.1,.7), there is 
> a .7 percent probability that it will transition to state 2.



--
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] [Updated] (SOLR-11602) Add Markov Chain Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11602:
--
Description: 
Now that Streaming Expressions supports Monte Carlo simulations it would be 
useful to also support Markov Chains 
(https://en.wikipedia.org/wiki/Markov_chain). This ticket will add support for 
Markov Chain simulations.

Here is the syntax:

{code}

let(state0=array(.3, .4, .3),
state1=array(.2, .1, .7),
state2=array(.6, .2, .2),
states=matrix(state0, state1, state2),
m=markovChain(states, 0),
s=sample(m, 500))
{code}

The Markov chain is initialized with a matrix who's rows represent the 
different *states* of the system. The columns represent the probabilities of 
changing from one state to another state.

For example if we are in state 1 represented by the array(.2,.1,.7), there is a 
.7 percent probability that it will transition to state 2.






  was:
Now that Streaming Expressions supports Monte Carlo simulations it would be 
useful to also support Markov Chains. This ticket will add support for Markov 
Chain simulations.

Here is the syntax:

{code}

let(state0=array(.3, .4, .3),
state1=array(.2, .1, .7),
state2=array(.6, .2, .2),
states=matrix(state0, state1, state2),
m=markovChain(states, 0),
s=sample(m, 500))
{code}

The Markov chain is initialized with a matrix who's rows represent the 
different *states* of the system. The columns represent the probabilities of 
changing from one state to another state.

For example if we are in state 1 represented by the array(.2,.1,.7), there is a 
.7 percent probability that it will transition to state 2.







> Add Markov Chain Stream Evaluator
> -
>
> Key: SOLR-11602
> URL: https://issues.apache.org/jira/browse/SOLR-11602
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11602.patch, SOLR-11602.patch, SOLR-11602.patch
>
>
> Now that Streaming Expressions supports Monte Carlo simulations it would be 
> useful to also support Markov Chains 
> (https://en.wikipedia.org/wiki/Markov_chain). This ticket will add support 
> for Markov Chain simulations.
> Here is the syntax:
> {code}
> let(state0=array(.3, .4, .3),
> state1=array(.2, .1, .7),
> state2=array(.6, .2, .2),
> states=matrix(state0, state1, state2),
> m=markovChain(states, 0),
> s=sample(m, 500))
> {code}
> The Markov chain is initialized with a matrix who's rows represent the 
> different *states* of the system. The columns represent the probabilities of 
> changing from one state to another state.
> For example if we are in state 1 represented by the array(.2,.1,.7), there is 
> a .7 percent probability that it will transition to state 2.



--
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-EA] Lucene-Solr-master-Linux (64bit/jdk-10-ea+29) - Build # 20818 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20818/
Java: 64bit/jdk-10-ea+29 -XX:-UseCompressedOops -XX:+UseSerialGC 
--illegal-access=deny

75 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.OverseerTest

Error Message:
29 threads leaked from SUITE scope at org.apache.solr.cloud.OverseerTest: 
1) Thread[id=11717, 
name=TEST-OverseerTest.testDoubleAssignment-seed#[393EAB7FEDECCD7D]-SendThread(127.0.0.1:39907),
 state=TIMED_WAITING, group=TGRP-OverseerTest] at 
java.base@10-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.zookeeper.ClientCnxnSocketNIO.cleanup(ClientCnxnSocketNIO.java:230)
 at 
app//org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1246)   
  at 
app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1170)2) 
Thread[id=11642, name=zkCallback-2892-thread-2, state=TIMED_WAITING, 
group=TGRP-OverseerTest] at 
java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@10-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@10-ea/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@10-ea/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@10-ea/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1060)
 at 
java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
 at 
java.base@10-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 at java.base@10-ea/java.lang.Thread.run(Thread.java:844)3) 
Thread[id=11628, name=Thread-2469-EventThread, state=WAITING, 
group=TGRP-OverseerTest] at 
java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@10-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2074)
 at 
java.base@10-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
 at 
app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501)4) 
Thread[id=11678, 
name=TEST-OverseerTest.testOverseerFailure-seed#[393EAB7FEDECCD7D]-SendThread(127.0.0.1:37473),
 state=TIMED_WAITING, group=TGRP-OverseerTest] at 
java.base@10-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:101)
 at 
app//org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:997)
 at 
app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1060)5) 
Thread[id=11609, 
name=TEST-OverseerTest.testBadQueueItem-seed#[393EAB7FEDECCD7D]-EventThread, 
state=WAITING, group=TGRP-OverseerTest] at 
java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@10-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2074)
 at 
java.base@10-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
 at 
app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501)6) 
Thread[id=11590, 
name=TEST-OverseerTest.testReplay-seed#[393EAB7FEDECCD7D]-SendThread(127.0.0.1:33095),
 state=TIMED_WAITING, group=TGRP-OverseerTest] at 
java.base@10-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1051)7) 
Thread[id=11718, 
name=TEST-OverseerTest.testDoubleAssignment-seed#[393EAB7FEDECCD7D]-EventThread,
 state=WAITING, group=TGRP-OverseerTest] at 
java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@10-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2074)
 at 
java.base@10-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
 at 
app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501)8) 
Thread[id=11657, 
name=TEST-OverseerTest.testShardAssignment-seed#[393EAB7FEDECCD7D]-SendThread(127.0.0.1:32965),
 state=TIMED_WAITING, group=TGRP-OverseerTest] at 
java.base@10-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1051)9) 
Thread[id=11736, 
name=TEST-OverseerTest.testRemovalOfLastReplica-seed#[393EAB7FEDECCD7D]-EventThread,
 sta

[jira] [Commented] (SOLR-11602) Add Markov Chain Stream Evaluator

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11602:


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

SOLR-11602: Add Markov Chain Stream Evaluator


> Add Markov Chain Stream Evaluator
> -
>
> Key: SOLR-11602
> URL: https://issues.apache.org/jira/browse/SOLR-11602
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11602.patch, SOLR-11602.patch, SOLR-11602.patch
>
>
> Now that Streaming Expressions supports Monte Carlo simulations it would be 
> useful to also support Markov Chains. This ticket will add support for Markov 
> Chain simulations.
> Here is the syntax:
> {code}
> let(state0=array(.3, .4, .3),
> state1=array(.2, .1, .7),
> state2=array(.6, .2, .2),
> states=matrix(state0, state1, state2),
> m=markovChain(states, 0),
> s=sample(m, 500))
> {code}
> The Markov chain is initialized with a matrix who's rows represent the 
> different *states* of the system. The columns represent the probabilities of 
> changing from one state to another state.
> For example if we are in state 1 represented by the array(.2,.1,.7), there is 
> a .7 percent probability that it will transition to state 2.



--
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-11602) Add Markov Chain Stream Evaluator

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11602:


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

SOLR-11602: Fix precommit


> Add Markov Chain Stream Evaluator
> -
>
> Key: SOLR-11602
> URL: https://issues.apache.org/jira/browse/SOLR-11602
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11602.patch, SOLR-11602.patch, SOLR-11602.patch
>
>
> Now that Streaming Expressions supports Monte Carlo simulations it would be 
> useful to also support Markov Chains. This ticket will add support for Markov 
> Chain simulations.
> Here is the syntax:
> {code}
> let(state0=array(.3, .4, .3),
> state1=array(.2, .1, .7),
> state2=array(.6, .2, .2),
> states=matrix(state0, state1, state2),
> m=markovChain(states, 0),
> s=sample(m, 500))
> {code}
> The Markov chain is initialized with a matrix who's rows represent the 
> different *states* of the system. The columns represent the probabilities of 
> changing from one state to another state.
> For example if we are in state 1 represented by the array(.2,.1,.7), there is 
> a .7 percent probability that it will transition to state 2.



--
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-11602) Add Markov Chain Stream Evaluator

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11602:


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

SOLR-11602: Fix precommit


> Add Markov Chain Stream Evaluator
> -
>
> Key: SOLR-11602
> URL: https://issues.apache.org/jira/browse/SOLR-11602
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11602.patch, SOLR-11602.patch, SOLR-11602.patch
>
>
> Now that Streaming Expressions supports Monte Carlo simulations it would be 
> useful to also support Markov Chains. This ticket will add support for Markov 
> Chain simulations.
> Here is the syntax:
> {code}
> let(state0=array(.3, .4, .3),
> state1=array(.2, .1, .7),
> state2=array(.6, .2, .2),
> states=matrix(state0, state1, state2),
> m=markovChain(states, 0),
> s=sample(m, 500))
> {code}
> The Markov chain is initialized with a matrix who's rows represent the 
> different *states* of the system. The columns represent the probabilities of 
> changing from one state to another state.
> For example if we are in state 1 represented by the array(.2,.1,.7), there is 
> a .7 percent probability that it will transition to state 2.



--
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-11602) Add Markov Chain Stream Evaluator

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11602:


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

SOLR-11602: Add Markov Chain Stream Evaluator


> Add Markov Chain Stream Evaluator
> -
>
> Key: SOLR-11602
> URL: https://issues.apache.org/jira/browse/SOLR-11602
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11602.patch, SOLR-11602.patch, SOLR-11602.patch
>
>
> Now that Streaming Expressions supports Monte Carlo simulations it would be 
> useful to also support Markov Chains. This ticket will add support for Markov 
> Chain simulations.
> Here is the syntax:
> {code}
> let(state0=array(.3, .4, .3),
> state1=array(.2, .1, .7),
> state2=array(.6, .2, .2),
> states=matrix(state0, state1, state2),
> m=markovChain(states, 0),
> s=sample(m, 500))
> {code}
> The Markov chain is initialized with a matrix who's rows represent the 
> different *states* of the system. The columns represent the probabilities of 
> changing from one state to another state.
> For example if we are in state 1 represented by the array(.2,.1,.7), there is 
> a .7 percent probability that it will transition to state 2.



--
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-Tests-master - Build # 2150 - Still unstable

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([4F0C3A59129E572E:C42BE9885398FCAA]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:185)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:140)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:135)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:908)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:428)
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.TestRuleIgnoreAfterMaxFailur

[jira] [Updated] (SOLR-11602) Add Markov Chain Stream Evaluator

[Joel Bernstein (JIRA)]

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

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

> Add Markov Chain Stream Evaluator
> -
>
> Key: SOLR-11602
> URL: https://issues.apache.org/jira/browse/SOLR-11602
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11602.patch, SOLR-11602.patch, SOLR-11602.patch
>
>
> Now that Streaming Expressions supports Monte Carlo simulations it would be 
> useful to also support Markov Chains. This ticket will add support for Markov 
> Chain simulations.
> Here is the syntax:
> {code}
> let(state0=array(.3, .4, .3),
> state1=array(.2, .1, .7),
> state2=array(.6, .2, .2),
> states=matrix(state0, state1, state2),
> m=markovChain(states, 0),
> s=sample(m, 500))
> {code}
> The Markov chain is initialized with a matrix who's rows represent the 
> different *states* of the system. The columns represent the probabilities of 
> changing from one state to another state.
> For example if we are in state 1 represented by the array(.2,.1,.7), there is 
> a .7 percent probability that it will transition to state 2.



--
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-10934) create a link+anchor checker for the ref-guide that only depends on ivy resources

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10934:


Commit 97e03125ef0d154e50f9cd7ad1315db5eaf44b95 in lucene-solr's branch 
refs/heads/branch_7x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=97e0312 ]

SOLR-10934: ref-guide link+anchor checking that doesn't require jekyll

(cherry picked from commit 7f033ac12bb290b2cbf5e43672932c31e8b0061a)


> create a link+anchor checker for the ref-guide that only depends on ivy 
> resources
> -
>
> Key: SOLR-10934
> URL: https://issues.apache.org/jira/browse/SOLR-10934
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-10934.patch, SOLR-10934.patch
>
>
> We currently have CheckLinksAndAnchors.java which is automatically run 
> against the ref-guide HTML as part of the build to use JSoup to find bad 
> links/anchors that asciidoctor doesn't complain about -- but not everyone 
> does/can build the HTML version of the ref-guide sincif we can e it requires 
> manually installing jekyll.
> This issue initially focused on trying to use PDFBox to do link+anchor 
> checking directly against the "final" PDF, but by that point a lot of 
> information that indicates problems (dup anchors, links pointing to the wrong 
> place in the document, etc...) is already lost.
> The current focus is on a way to catch all of the same types of problems we 
> can currently catch today, in a way that anyone can run purely from ant -- 
> w/o any manually instaled tools like jekyll.



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

Potential bug in UsageTrackingQueryCachingPolicy

[Jon Harper]

Hi,

I'm looking at lucene-core UsageTrackingQueryCachingPolicy.java (caching
policy for the LRUCache), one line of code looks dubious in the
shouldNeverCache method

The comment says "For the below queries, it's cheap to notice they cannot
match any docs so we do not bother caching them. "  but then returns
false to shouldnevercache for MatchNoDocsQuery

Note that empty BooleanQuery and empty DisjunctionMaxQuery return true and
hence are never cached

Here's a github link to the line in question for easy and quick access.

https://github.com/apache/lucene-solr/blob/1d2787464f4709f4960716dd3314c7123324b15b/lucene/core/src/java/org/apache/lucene/search/UsageTrackingQueryCachingPolicy.java#L71


Regards,
Jon

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CloudExitableDirectoryReaderTest

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at __randomizedtesting.SeedInfo.seed([47641A7F96BAAFC0]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1325)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.waitForState(CloudSolrClient.java:440)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.setupCluster(CloudExitableDirectoryReaderTest.java:49)
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.TestRebalanceLeaders.test

Error Message:
Waited for timeout for preferredLeader assignments to be made and they werent.

Stack Trace:
java.lang.AssertionError: Waited for timeout for preferredLeader assignments to 
be made and they werent.
at 
__randomizedtesting.SeedInfo.seed([47641A7F96BAAFC0:CF3025A53846C238]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.TestRebalanceLeaders.issueCommands(TestRebalanceLeaders.java:277)
at 
org.apache.solr.cloud.TestRebalanceLeaders.rebalanceLeaderTest(TestRebalanceLeaders.java:111)
at 
org.apache.solr.cloud.TestRebalanceLeaders.test(TestRebalanceLeaders.java:77)
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 

[jira] [Commented] (SOLR-10934) create a link+anchor checker for the ref-guide that only depends on ivy resources

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10934:


Commit 7f033ac12bb290b2cbf5e43672932c31e8b0061a in lucene-solr's branch 
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7f033ac ]

SOLR-10934: ref-guide link+anchor checking that doesn't require jekyll


> create a link+anchor checker for the ref-guide that only depends on ivy 
> resources
> -
>
> Key: SOLR-10934
> URL: https://issues.apache.org/jira/browse/SOLR-10934
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-10934.patch, SOLR-10934.patch
>
>
> We currently have CheckLinksAndAnchors.java which is automatically run 
> against the ref-guide HTML as part of the build to use JSoup to find bad 
> links/anchors that asciidoctor doesn't complain about -- but not everyone 
> does/can build the HTML version of the ref-guide sincif we can e it requires 
> manually installing jekyll.
> This issue initially focused on trying to use PDFBox to do link+anchor 
> checking directly against the "final" PDF, but by that point a lot of 
> information that indicates problems (dup anchors, links pointing to the wrong 
> place in the document, etc...) is already lost.
> The current focus is on a way to catch all of the same types of problems we 
> can currently catch today, in a way that anyone can run purely from ant -- 
> w/o any manually instaled tools like jekyll.



--
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 (64bit/jdk-9.0.1) - Build # 284 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/284/
Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseG1GC --illegal-access=deny

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.codecs.perfield.TestPerFieldPostingsFormat

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J1\temp\lucene.codecs.perfield.TestPerFieldPostingsFormat_B2280F3FDCEAC0C5-001\justSoYouGetSomeChannelErrors-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J1\temp\lucene.codecs.perfield.TestPerFieldPostingsFormat_B2280F3FDCEAC0C5-001\justSoYouGetSomeChannelErrors-001

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J1\temp\lucene.codecs.perfield.TestPerFieldPostingsFormat_B2280F3FDCEAC0C5-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J1\temp\lucene.codecs.perfield.TestPerFieldPostingsFormat_B2280F3FDCEAC0C5-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J1\temp\lucene.codecs.perfield.TestPerFieldPostingsFormat_B2280F3FDCEAC0C5-001\justSoYouGetSomeChannelErrors-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J1\temp\lucene.codecs.perfield.TestPerFieldPostingsFormat_B2280F3FDCEAC0C5-001\justSoYouGetSomeChannelErrors-001
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J1\temp\lucene.codecs.perfield.TestPerFieldPostingsFormat_B2280F3FDCEAC0C5-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\J1\temp\lucene.codecs.perfield.TestPerFieldPostingsFormat_B2280F3FDCEAC0C5-001

at __randomizedtesting.SeedInfo.seed([B2280F3FDCEAC0C5]: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.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest.testConsistencyOnExceptions

Error Message:
Captured an uncaught exception in thread: Thread[id=15, 
name=ReplicationThread-indexAndTaxo, state=RUNNABLE, 
group=TGRP-IndexAndTaxonomyReplicationClientTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=15, name=ReplicationThread-indexAndTaxo, 
state=RUNNABLE, group=TGRP-IndexAndTaxonomyReplicationClientTest]
at 
__randomizedtesting.SeedInfo.seed([3D0B43D9225166B5:B285A479303D954A]:0)
Caused by: java.lang.AssertionError: handler failed too many times: -1
at __randomizedtesting.SeedInfo.seed([3D0B43D9225166B5]:0)
at 
org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest$4.handleUpdateException(IndexAndTaxonomyReplicationClientTest.java:422)
at 
org.apache.lucene.replicator.ReplicationClient$ReplicationThread.run(ReplicationClient.java:77)


FAILED:  
junit.framework.TestSuite.org.apache.lucene.search.suggest.analyzing.AnalyzingSuggesterTest

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\suggest\test\J1\temp\lucene.search.suggest.analyzing.AnalyzingSuggesterTest_C7A0214857C8574-001\AnalyzingSuggesterTest-004:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\suggest\test\J1\temp\lucene.search.suggest.analyzing.AnalyzingSuggesterTest_C7A0214857C8574-001\AnalyzingSuggesterTest-004

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\suggest\test\J1\temp\lucene.search.suggest.analyzing.AnalyzingSug

[jira] [Assigned] (SOLR-10934) create a link+anchor checker for the ref-guide that only depends on ivy resources

[Hoss Man (JIRA)]

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

Hoss Man reassigned SOLR-10934:
---

   Assignee: Hoss Man
Description: 
We currently have CheckLinksAndAnchors.java which is automatically run against 
the ref-guide HTML as part of the build to use JSoup to find bad links/anchors 
that asciidoctor doesn't complain about -- but not everyone does/can build the 
HTML version of the ref-guide sincif we can e it requires manually installing 
jekyll.

This issue initially focused on trying to use PDFBox to do link+anchor checking 
directly against the "final" PDF, but by that point a lot of information that 
indicates problems (dup anchors, links pointing to the wrong place in the 
document, etc...) is already lost.

The current focus is on a way to catch all of the same types of problems we can 
currently catch today, in a way that anyone can run purely from ant -- w/o any 
manually instaled tools like jekyll.


  was:
We currently have CheckLinksAndAnchors.java which is automatically run against 
the ref-guide HTML as part of the build to use JSoup to find bad links/anchors 
that asciidoctor doesn't complain about -- but not everyone does/can build the 
HTML version of the ref-guide sincif we can e it requires manually installing 
jekyll.

The PDF build only requires things installed by ivy (via JRuby) and we already 
have some PDFBox based code in ReducePDFSize.java that operates on this PDF 
every time it's run -- so if we can find a way to do similar checks using the 
PDFBox API we could catch these broken links faster.

Summary: create a link+anchor checker for the ref-guide that only 
depends on ivy resources  (was: create a link+anchor checker for the ref-guide 
PDF using PDFBox)

> create a link+anchor checker for the ref-guide that only depends on ivy 
> resources
> -
>
> Key: SOLR-10934
> URL: https://issues.apache.org/jira/browse/SOLR-10934
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-10934.patch, SOLR-10934.patch
>
>
> We currently have CheckLinksAndAnchors.java which is automatically run 
> against the ref-guide HTML as part of the build to use JSoup to find bad 
> links/anchors that asciidoctor doesn't complain about -- but not everyone 
> does/can build the HTML version of the ref-guide sincif we can e it requires 
> manually installing jekyll.
> This issue initially focused on trying to use PDFBox to do link+anchor 
> checking directly against the "final" PDF, but by that point a lot of 
> information that indicates problems (dup anchors, links pointing to the wrong 
> place in the document, etc...) is already lost.
> The current focus is on a way to catch all of the same types of problems we 
> can currently catch today, in a way that anyone can run purely from ant -- 
> w/o any manually instaled tools like jekyll.



--
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] [Updated] (SOLR-11602) Add Markov Chain Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11602:
--
Description: 
Now that Streaming Expressions supports Monte Carlo simulations it would be 
useful to also support Markov Chains. This ticket will add support for Markov 
Chain simulations.

Here is the syntax:

{code}

let(state0=array(.3, .4, .3),
state1=array(.2, .1, .7),
state2=array(.6, .2, .2),
states=matrix(state0, state1, state2),
m=markovChain(states, 0),
s=sample(m, 500))
{code}

The Markov chain is initialized with a matrix who's rows represent the 
different *states* of the system. The columns represent the probabilities of 
changing from one state to another state.

For example if we are in state 1 represented by the array(.2,.1,.7), there is a 
.7 percent probability that it will transition to state 2.






  was:
Now that Streaming Expressions supports Monte Carlo simulations it would be 
useful to also support Markov Chains. This ticket will add support for Markov 
Chain simulations.

Here is the syntax:

{code}

let(state0=array(.3, .4, .3),
state1=array(.2, .1, .7),
state2=array(.6, .2, .2),
states=matrix(state0, state1, state2),
m=markovChain(states, 0),
s=sample(m, 500))
{code}

The Markov chain is initialized with a matrix who's rows represent the 
different *states* of the system. The columns represent the probabilities of 
changing from one state to another state.

For example if we are in state 1 represented by the array(.2,.1,.7), there is a 
.7 percent probability that it transition to state 2.







> Add Markov Chain Stream Evaluator
> -
>
> Key: SOLR-11602
> URL: https://issues.apache.org/jira/browse/SOLR-11602
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11602.patch, SOLR-11602.patch
>
>
> Now that Streaming Expressions supports Monte Carlo simulations it would be 
> useful to also support Markov Chains. This ticket will add support for Markov 
> Chain simulations.
> Here is the syntax:
> {code}
> let(state0=array(.3, .4, .3),
> state1=array(.2, .1, .7),
> state2=array(.6, .2, .2),
> states=matrix(state0, state1, state2),
> m=markovChain(states, 0),
> s=sample(m, 500))
> {code}
> The Markov chain is initialized with a matrix who's rows represent the 
> different *states* of the system. The columns represent the probabilities of 
> changing from one state to another state.
> For example if we are in state 1 represented by the array(.2,.1,.7), there is 
> a .7 percent probability that it will transition to state 2.



--
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] [Updated] (SOLR-11602) Add Markov Chain Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11602:
--
Description: 
Now that Streaming Expressions supports Monte Carlo simulations it would be 
useful to also support Markov Chains. This ticket will add support for Markov 
Chain simulations.

Here is the syntax:

{code}

let(state0=array(.3, .4, .3),
state1=array(.2, .1, .7),
state2=array(.6, .2, .2),
states=matrix(state0, state1, state2),
m=markovChain(states, 0),
s=sample(m, 500))
{code}

The Markov chain is initialized with a matrix who's rows represent the 
different *states* of the system. The columns represent the probabilities of 
changing from one state to another state.

For example if we are in state 1 represented by the array(.2,.1,.7), there is a 
.7 percent probability that it transition to state 2.






  was:
Now that Streaming Expressions supports Monte Carlo simulations it would be 
useful to also support Markov Chains. This ticket will add support for Markov 
Chain simulations.

Here is the syntax:

{code}

let(state0=array(.3, .4, .3),
state1=array(.2, .1, .7),
state2=array(.6, .2, .2),
states=matrix(state0, state1, state2),
m=markovChain(states, 0),
s=sample(m, 500))
{code}

The Markov chain is initialized with an matrix who's rows represent the 
different *states* of the system. The columns represent the probabilities of 
changing from one state to another state.

For example if we are in state 1 represented by the array(.2,.1,.7), there is a 
.7 percent probability that it transition to state 2.







> Add Markov Chain Stream Evaluator
> -
>
> Key: SOLR-11602
> URL: https://issues.apache.org/jira/browse/SOLR-11602
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11602.patch, SOLR-11602.patch
>
>
> Now that Streaming Expressions supports Monte Carlo simulations it would be 
> useful to also support Markov Chains. This ticket will add support for Markov 
> Chain simulations.
> Here is the syntax:
> {code}
> let(state0=array(.3, .4, .3),
> state1=array(.2, .1, .7),
> state2=array(.6, .2, .2),
> states=matrix(state0, state1, state2),
> m=markovChain(states, 0),
> s=sample(m, 500))
> {code}
> The Markov chain is initialized with a matrix who's rows represent the 
> different *states* of the system. The columns represent the probabilities of 
> changing from one state to another state.
> For example if we are in state 1 represented by the array(.2,.1,.7), there is 
> a .7 percent probability that it transition to state 2.



--
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] [Updated] (SOLR-11602) Add Markov Chain Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11602:
--
Description: 
Now that Streaming Expressions supports Monte Carlo simulations it would be 
useful to also support Markov Chains. This ticket will add support for Markov 
Chain simulations.

Here is the syntax:

{code}

let(state0=array(.3, .4, .3),
state1=array(.2, .1, .7),
state2=array(.6, .2, .2),
states=matrix(state0, state1, state2),
m=markovChain(states, 0),
s=sample(m, 500))
{code}

The Markov chain is initialized with an matrix who's rows represent the 
different *states* of the system. The columns represent the probabilities of 
changing from one state to another state.

For example if we are in state 1 represented by the array(.2,.1,.7), there is a 
.7 percent probability that it transition to state 2.






  was:
Now that Streaming Expressions supports Monte Carlo simulations it would be 
useful to also support Markov Chains. This ticket will add support for Markov 
Chain simulations.

Here is the syntax:

{code}

let(state0=array(.3, .4, .3),
 state1=array(.2, .1, .7),
 state2=array(.6, .2, .2),
 states=matrix(state0, state1, state2),
 m=markovChain(states, 0),
 s=sample(m, 500))
{code}

The Markov chain is initialized with an matrix who's rows represent the 
different *states* of the system. The columns represent the probabilities of 
changing from one state to another state.

For example if we are in state 1 represented by the array(.2,.1,.7), there is a 
.7 percent probability that it transition to state 2.







> Add Markov Chain Stream Evaluator
> -
>
> Key: SOLR-11602
> URL: https://issues.apache.org/jira/browse/SOLR-11602
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11602.patch, SOLR-11602.patch
>
>
> Now that Streaming Expressions supports Monte Carlo simulations it would be 
> useful to also support Markov Chains. This ticket will add support for Markov 
> Chain simulations.
> Here is the syntax:
> {code}
> let(state0=array(.3, .4, .3),
> state1=array(.2, .1, .7),
> state2=array(.6, .2, .2),
> states=matrix(state0, state1, state2),
> m=markovChain(states, 0),
> s=sample(m, 500))
> {code}
> The Markov chain is initialized with an matrix who's rows represent the 
> different *states* of the system. The columns represent the probabilities of 
> changing from one state to another state.
> For example if we are in state 1 represented by the array(.2,.1,.7), there is 
> a .7 percent probability that it transition to state 2.



--
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] [Updated] (SOLR-11602) Add Markov Chain Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11602:
--
Description: 
Now that Streaming Expressions supports Monte Carlo simulations it would be 
useful to also support Markov Chains. This ticket will add support for Markov 
Chain simulations.

Here is the syntax:

{code}

let(state0=array(.3, .4, .3),
 state1=array(.2, .1, .7),
 state2=array(.6, .2, .2),
 states=matrix(state0, state1, state2),
 m=markovChain(states, 0),
 s=sample(m, 500))
{code}

The Markov chain is initialized with an matrix who's rows represent the 
different *states* of the system. The columns represent the probabilities of 
changing from one state to another state.

For example if we are in state 1 represented by the array(.2,.1,.7), there is a 
.7 percent probability that it transition to state 2.






  was:Now that Streaming Expressions supports Monte Carlo simulations it would 
be useful to also support Markov Chains. This ticket will add support for 
Markov Chain simulations.


> Add Markov Chain Stream Evaluator
> -
>
> Key: SOLR-11602
> URL: https://issues.apache.org/jira/browse/SOLR-11602
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11602.patch, SOLR-11602.patch
>
>
> Now that Streaming Expressions supports Monte Carlo simulations it would be 
> useful to also support Markov Chains. This ticket will add support for Markov 
> Chain simulations.
> Here is the syntax:
> {code}
> let(state0=array(.3, .4, .3),
>  state1=array(.2, .1, .7),
>  state2=array(.6, .2, .2),
>  states=matrix(state0, state1, state2),
>  m=markovChain(states, 0),
>  s=sample(m, 500))
> {code}
> The Markov chain is initialized with an matrix who's rows represent the 
> different *states* of the system. The columns represent the probabilities of 
> changing from one state to another state.
> For example if we are in state 1 represented by the array(.2,.1,.7), there is 
> a .7 percent probability that it transition to state 2.



--
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] [Updated] (SOLR-11602) Add Markov Chain Stream Evaluator

[Joel Bernstein (JIRA)]

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

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

> Add Markov Chain Stream Evaluator
> -
>
> Key: SOLR-11602
> URL: https://issues.apache.org/jira/browse/SOLR-11602
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11602.patch, SOLR-11602.patch
>
>
> Now that Streaming Expressions supports Monte Carlo simulations it would be 
> useful to also support Markov Chains. This ticket will add support for Markov 
> Chain simulations.



--
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: JDK 10 b29 Early Access is available on jdk.java.net

[Rory O'Donnell]

Thanks Uwe, looking forward to your report !

Rgds,Rory


On 03/11/2017 15:23, Uwe Schindler wrote:


Hi Rory,

I just came back from J-Fall 2017. Thanks for the update about new EA 
builds! I was waiting for it, and now I can try it out, cool. I will 
report back soon, once I added JDK 10 to our Jenkins Cluster.


We are happy to see the new version numbering proposal that uses the 
usual major.minor pattern, counting from 10 onwards instead of the 
year-month style; Dalibor and I discussed about it on our train ride 
today! When testing the new builds, I hope this time nothing breaks 
because the main version number has suddenly 2 digits 😊.


Uwe

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de 

eMail: u...@thetaphi.de

*From:*Rory O'Donnell [mailto:rory.odonn...@oracle.com]
*Sent:* Friday, November 3, 2017 10:48 AM
*To:* dawid.we...@cs.put.poznan.pl; u...@thetaphi.de
*Cc:* rory.odonn...@oracle.com; Dalibor Topic 
; Balchandra Vaidya 
; Muneer Kolarkunnu 
; dev@lucene.apache.org

*Subject:* JDK 10 b29 Early Access is available on jdk.java.net


Hi Uwe & Dawid,

JDK 10 Early Access  build 29 is available at : - jdk.java.net/10/

JDK 10 Early Access Release Notes are available [1]

JDK 10 Schedule, Status & Features are available [2]


  Notes

  * OpenJDK EA binaries will be available at a later date.
  * Oracle has proposed: Newer version-string scheme for the Java SE
Platform and the JDK

  o Please see Mark Reinhold's proposal [3] , feedback via the
mailing list to Mark please.

Feedback - If you have suggestions or encounter bugs, please submit 
them using the usual Java SE bug-reporting channel.
Be sure to include complete version information from the output of the 
|java --version| command.


Regards,
Rory

[1] http://jdk.java.net/10/release-notes
[2] http://openjdk.java.net/projects/jdk/10/
[3] 
http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/89.html


--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

[jira] [Updated] (SOLR-11602) Add Markov Chain Stream Evaluator

[Joel Bernstein (JIRA)]

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

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

> Add Markov Chain Stream Evaluator
> -
>
> Key: SOLR-11602
> URL: https://issues.apache.org/jira/browse/SOLR-11602
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11602.patch
>
>
> Now that Streaming Expressions supports Monte Carlo simulations it would be 
> useful to also support Markov Chains. This ticket will add support for Markov 
> Chain simulations.



--
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-Windows (32bit/jdk1.8.0_144) - Build # 6996 - Still unstable!

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_A17673EE0DAA19D0-001\justSoYouGetSomeChannelErrors-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_A17673EE0DAA19D0-001\justSoYouGetSomeChannelErrors-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\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_A17673EE0DAA19D0-001\justSoYouGetSomeChannelErrors-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\codecs\test\J1\temp\lucene.codecs.blockterms.TestVarGapDocFreqIntervalPostingsFormat_A17673EE0DAA19D0-001\justSoYouGetSomeChannelErrors-001

at __randomizedtesting.SeedInfo.seed([A17673EE0DAA19D0]: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:  junit.framework.TestSuite.org.apache.lucene.mockfile.TestHandleLimitFS

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestHandleLimitFS_5183479F285E38D1-001\tempDir-007:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestHandleLimitFS_5183479F285E38D1-001\tempDir-007

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestHandleLimitFS_5183479F285E38D1-001\tempDir-007\89539547606314024.tmp:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestHandleLimitFS_5183479F285E38D1-001\tempDir-007\89539547606314024.tmp

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestHandleLimitFS_5183479F285E38D1-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestHandleLimitFS_5183479F285E38D1-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\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestHandleLimitFS_5183479F285E38D1-001\tempDir-007:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestHandleLimitFS_5183479F285E38D1-001\tempDir-007
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestHandleLimitFS_5183479F285E38D1-001\tempDir-007\89539547606314024.tmp:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestHandleLimitFS_5183479F285E38D1-001\tempDir-007\89539547606314024.tmp
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J0\temp\lucene.mockfile.TestHandleLimitFS_5183479F285E38D1-001:
 java.nio.file.DirectoryNotEmptyExcep

[jira] [Updated] (SOLR-11602) Add Markov Chain Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11602:
--
Fix Version/s: 7.2

> Add Markov Chain Stream Evaluator
> -
>
> Key: SOLR-11602
> URL: https://issues.apache.org/jira/browse/SOLR-11602
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
>
> Now that Streaming Expressions supports Monte Carlo simulations it would be 
> useful to also support Markov Chains. This ticket will add support for Markov 
> Chain simulations.



--
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] [Updated] (SOLR-11602) Add Markov Chain Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11602:
--
Description: Now that Streaming Expressions supports Monte Carlo 
simulations it would be useful to also support Markov Chains. This ticket will 
add support for Markov Chain simulations.  (was: Now that Streaming Expressions 
supports Monte Carlo simulations it would be useful to also support Markov 
Chains. This will add support for a Markov Chains.)

> Add Markov Chain Stream Evaluator
> -
>
> Key: SOLR-11602
> URL: https://issues.apache.org/jira/browse/SOLR-11602
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
>
> Now that Streaming Expressions supports Monte Carlo simulations it would be 
> useful to also support Markov Chains. This ticket will add support for Markov 
> Chain simulations.



--
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] [Assigned] (SOLR-11602) Add Markov Chain Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-11602:
-

Assignee: Joel Bernstein

> Add Markov Chain Stream Evaluator
> -
>
> Key: SOLR-11602
> URL: https://issues.apache.org/jira/browse/SOLR-11602
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
>
> Now that Streaming Expressions supports Monte Carlo simulations it would be 
> useful to also support Markov Chains. This will add support for a Markov 
> Chains.



--
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-11602) Add Markov Chain Stream Evaluator

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-11602:
-

 Summary: Add Markov Chain Stream Evaluator
 Key: SOLR-11602
 URL: https://issues.apache.org/jira/browse/SOLR-11602
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


Now that Streaming Expressions supports Monte Carlo simulations it would be 
useful to also support Markov Chains. This will add support for a Markov Chains.



--
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: JDK 10 b29 Early Access is available on jdk.java.net

[Uwe Schindler]

Hi Rory,

 

I just came back from J-Fall 2017. Thanks for the update about new EA builds! I 
was waiting for it, and now I can try it out, cool. I will report back soon, 
once I added JDK 10 to our Jenkins Cluster.

 

We are happy to see the new version numbering proposal that uses the usual 
major.minor pattern, counting from 10 onwards instead of the year-month style; 
Dalibor and I discussed about it on our train ride today! When testing the new 
builds, I hope this time nothing breaks because the main version number has 
suddenly 2 digits 😊.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: Rory O'Donnell [mailto:rory.odonn...@oracle.com] 
Sent: Friday, November 3, 2017 10:48 AM
To: dawid.we...@cs.put.poznan.pl; u...@thetaphi.de
Cc: rory.odonn...@oracle.com; Dalibor Topic ; 
Balchandra Vaidya ; Muneer Kolarkunnu 
; dev@lucene.apache.org
Subject: JDK 10 b29 Early Access is available on jdk.java.net

 

 


Hi Uwe & Dawid, 

JDK 10 Early Access  build 29 is available at : - jdk.java.net/10/

JDK 10 Early Access Release Notes are available [1]

JDK 10 Schedule, Status & Features are available [2]


Notes


*   OpenJDK EA binaries will be available at a later date.
*   Oracle has proposed: Newer version-string scheme for the Java SE 
Platform and the JDK 

*   Please see Mark Reinhold's proposal [3] , feedback via the mailing list 
to Mark please.

Feedback - If you have suggestions or encounter bugs, please submit them using 
the usual Java SE bug-reporting channel. 
Be sure to include complete version information from the output of the java 
--version command.

Regards,
Rory

[1] http://jdk.java.net/10/release-notes
[2] http://openjdk.java.net/projects/jdk/10/
[3] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/89.html



-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland 

[jira] [Comment Edited] (SOLR-11581) NoMergeScheduler ctor should be public for allowing instantiation from SOLR

[Nawab Zada Asad iqbal (JIRA)]

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

Nawab Zada Asad iqbal edited comment on SOLR-11581 at 11/3/17 3:15 PM:
---

Thanks Amrit, and Michael. 

I am already doing most of what you are recommending. I want to write a blog on 
it, once I successfully upgrade to solr 7 and also look forward to your Amrit's 
article. -Though, we don't use "useCompondFile" for the sake of better query 
performance. -  (EDIT, I later found that this perception of 'useCompoundFile' 
is wrong)

Michael: In our current design, we bulk index all the accumulated documents, 
then merge explicitly to an optimal number of segments (10 or so). Only then we 
start live indexing and query traffic to the servers (there are some 
intermediate steps to replace solrconfig and also index for the time taken 
during bulk indexing). In earlier experiments with older Solr versions, keeping 
merging ON while bulk indexing slowed down the whole process. 




was (Author: niqbal):
Thanks Amrit, and Michael. 

I am already doing most of what you are recommending. I want to write a blog on 
it, once I successfully upgrade to solr 7 and also look forward to your Amrit's 
article. -Though, we don't use "useCompondFile" for the sake of better query 
performance. -  (EDIT, I later found that this perception is wrong)

Michael: In our current design, we bulk index all the accumulated documents, 
then merge explicitly to an optimal number of segments (10 or so). Only then we 
start live indexing and query traffic to the servers (there are some 
intermediate steps to replace solrconfig and also index for the time taken 
during bulk indexing). In earlier experiments with older Solr versions, keeping 
merging ON while bulk indexing slowed down the whole process. 



> NoMergeScheduler ctor should be public for allowing instantiation from SOLR
> ---
>
> Key: SOLR-11581
> URL: https://issues.apache.org/jira/browse/SOLR-11581
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Nawab Zada Asad iqbal
>Priority: Minor
>
> There are scenarios where a SOLR user may want to use NoMergeScheduler. 
> However, it is not possible to use it today, since its constructor is private 
> and solrconfig.xml requires a Scheduler with public constructor.



--
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-11581) NoMergeScheduler ctor should be public for allowing instantiation from SOLR

[Nawab Zada Asad iqbal (JIRA)]

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

Nawab Zada Asad iqbal commented on SOLR-11581:
--

Amrit, 

After reading your question, I am now realizing that `compoundFile` is not what 
i understood it to be; and it is a temporary file during indexing. My 
perception was based on this comment in  a `solrconfig` which comes out of the 
box. 


{code:java}


{code}


> NoMergeScheduler ctor should be public for allowing instantiation from SOLR
> ---
>
> Key: SOLR-11581
> URL: https://issues.apache.org/jira/browse/SOLR-11581
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Nawab Zada Asad iqbal
>Priority: Minor
>
> There are scenarios where a SOLR user may want to use NoMergeScheduler. 
> However, it is not possible to use it today, since its constructor is private 
> and solrconfig.xml requires a Scheduler with public constructor.



--
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] [Comment Edited] (SOLR-11581) NoMergeScheduler ctor should be public for allowing instantiation from SOLR

[Nawab Zada Asad iqbal (JIRA)]

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

Nawab Zada Asad iqbal edited comment on SOLR-11581 at 11/3/17 3:12 PM:
---

Thanks Amrit, and Michael. 

I am already doing most of what you are recommending. I want to write a blog on 
it, once I successfully upgrade to solr 7 and also look forward to your Amrit's 
article. -Though, we don't use "useCompondFile" for the sake of better query 
performance. -  (EDIT, I later found that this perception is wrong)

Michael: In our current design, we bulk index all the accumulated documents, 
then merge explicitly to an optimal number of segments (10 or so). Only then we 
start live indexing and query traffic to the servers (there are some 
intermediate steps to replace solrconfig and also index for the time taken 
during bulk indexing). In earlier experiments with older Solr versions, keeping 
merging ON while bulk indexing slowed down the whole process. 




was (Author: niqbal):
Thanks Amrit, and Michael. 

I am already doing most of what you are recommending. I want to write a blog on 
it, once I successfully upgrade to solr 7 and also look forward to your Amrit's 
article. Though, we don't use "useCompondFile" for the sake of better query 
performance. 

Michael: In our current design, we bulk index all the accumulated documents, 
then merge explicitly to an optimal number of segments (10 or so). Only then we 
start live indexing and query traffic to the servers (there are some 
intermediate steps to replace solrconfig and also index for the time taken 
during bulk indexing). In earlier experiments with older Solr versions, keeping 
merging ON while bulk indexing slowed down the whole process. 



> NoMergeScheduler ctor should be public for allowing instantiation from SOLR
> ---
>
> Key: SOLR-11581
> URL: https://issues.apache.org/jira/browse/SOLR-11581
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Nawab Zada Asad iqbal
>Priority: Minor
>
> There are scenarios where a SOLR user may want to use NoMergeScheduler. 
> However, it is not possible to use it today, since its constructor is private 
> and solrconfig.xml requires a Scheduler with public constructor.



--
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: Dev-subscribe

[Erick Erickson]

Please follow the instructions here:
http://lucene.apache.org/solr/community.html#mailing-lists-irc. You
must use the _exact_ same e-mail as you used to subscribe.

If the initial try doesn't work and following the suggestions at the
"problems" link doesn't work for you, let us know. But note you need
to show us the _entire_ return header to allow anyone to diagnose the
problem.

Best,
Erick

On Thu, Nov 2, 2017 at 11:16 PM, Chandra Gopalaiah
 wrote:
>

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

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

[Policeman Jenkins Server]

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

7 tests failed.
FAILED:  
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testRetryUpdatesWhenClusterStateIsStale

Error Message:
Error from server at http://127.0.0.1:55098/solr: Error waiting for corenode 
gone

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:55098/solr: Error waiting for corenode gone
at 
__randomizedtesting.SeedInfo.seed([944D37FAA4ECF424:207CAF1247058208]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
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:1096)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:183)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:200)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testRetryUpdatesWhenClusterStateIsStale(CloudSolrClientTest.java:834)
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 
co

[jira] [Commented] (SOLR-11409) A ref guide page on setting up solr on aws

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-11409:
--

bq. I can remove that "bold" NOTE and upload new patch, let me know

Since I'm working on it already I'll fix it up, thanks for offering.

bq. we can safely deploy production system on EC2 instances. The quick start is 
the base to understand how to establish a dev environment but need further 
pointers for production

I'll make this point a bit more clear also.

> A ref guide page on setting up solr on aws
> --
>
> Key: SOLR-11409
> URL: https://issues.apache.org/jira/browse/SOLR-11409
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Priority: Minor
> Attachments: SOLR-11409.patch, quick-start-aws-key.png, 
> quick-start-aws-security-1.png, quick-start-aws-security-2.png
>
>
> It will be nice if we have a dedicated page on installing solr on aws . 
> At the end we could even link to 
> http://lucene.apache.org/solr/guide/6_6/taking-solr-to-production.html



--
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-7994) Use int/int hash map for int taxonomy facet counts

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7994: Add facets lib/ directory to IntelliJ setup


> Use int/int hash map for int taxonomy facet counts
> --
>
> Key: LUCENE-7994
> URL: https://issues.apache.org/jira/browse/LUCENE-7994
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Major
> Fix For: master (8.0), 7.2
>
> Attachments: LUCENE-7994.patch, LUCENE-7994.patch
>
>
> Int taxonomy facets today always count into a dense {{int[]}}, which is 
> wasteful in cases where the number of unique facet labels is high and the 
> size of the current result set is small.
> I factored the native hash map from LUCENE-7927 and use a simple heuristic 
> (customizable by the user by subclassing) to decide up front whether to count 
> sparse or dense.  I also made loading of the large children and siblings 
> {{int[]}} lazy, so that they are only instantiated if you really need them.



--
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-7994) Use int/int hash map for int taxonomy facet counts

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7994: Add facets lib/ directory to IntelliJ setup


> Use int/int hash map for int taxonomy facet counts
> --
>
> Key: LUCENE-7994
> URL: https://issues.apache.org/jira/browse/LUCENE-7994
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Major
> Fix For: master (8.0), 7.2
>
> Attachments: LUCENE-7994.patch, LUCENE-7994.patch
>
>
> Int taxonomy facets today always count into a dense {{int[]}}, which is 
> wasteful in cases where the number of unique facet labels is high and the 
> size of the current result set is small.
> I factored the native hash map from LUCENE-7927 and use a simple heuristic 
> (customizable by the user by subclassing) to decide up front whether to count 
> sparse or dense.  I also made loading of the large children and siblings 
> {{int[]}} lazy, so that they are only instantiated if you really need them.



--
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-11581) NoMergeScheduler ctor should be public for allowing instantiation from SOLR

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-11581:
-

Nawab,

> Though, we don't use "useCompondFile" for the sake of better query 
> performance.

Can you share a brief explanation or resource on how "compound file segments" 
deteriorates query performance. We did some test son our own at workplace and 
didn't find any reason for not using "compound file segments".

> NoMergeScheduler ctor should be public for allowing instantiation from SOLR
> ---
>
> Key: SOLR-11581
> URL: https://issues.apache.org/jira/browse/SOLR-11581
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Nawab Zada Asad iqbal
>Priority: Minor
>
> There are scenarios where a SOLR user may want to use NoMergeScheduler. 
> However, it is not possible to use it today, since its constructor is private 
> and solrconfig.xml requires a Scheduler with public constructor.



--
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: [JENKINS] Lucene-Solr-7.x-Windows (32bit/jdk1.8.0_144) - Build # 282 - Still Failing!

[Steve Rowe]

Hi Uwe,

> On Nov 3, 2017, at 4:11 AM, Uwe Schindler  wrote:
> 
> Hi Steve,
> 
> I was on a conference yesterday, sorry for the delay. I deleted the file. How 
> did you get rid of the Linux/Mac/Solaris ones (because I checked for the 
> existence of the old version, too)?

The ivy-bootstrap target now deletes old versions.

> Should I keep the ivy-bootstrap jobs or delete them? For Policeman they are 
> not really needed as we have shell access.

I think it’s fine to delete them.

> Uwe
> 
> P.S.: If you send me your SSH key, I can give you SSH access to all the 
> jenkins accounts on all 4 machines.

Thanks, I’ll send it separately.

--
Steve
www.lucidworks.com

>> -Original Message-
>> From: Steve Rowe [mailto:sar...@gmail.com]
>> Sent: Friday, November 3, 2017 1:39 AM
>> To: Uwe Schindler 
>> Cc: Lucene Dev 
>> Subject: Re: [JENKINS] Lucene-Solr-7.x-Windows (32bit/jdk1.8.0_144) - Build #
>> 282 - Still Failing!
>> 
>> Hi Uwe,
>> 
>> After upgrading the Lucene/Solr Ivy version to 2.4.0 on master and
>> branch_7x, I created jobs on Policeman Jenkins to run ‘ant ivy-bootstrap’ for
>> each VBOX and then ran them.  However, the 2.3.0 jar can’t be deleted from
>> the Windows VBOX for some reason, so further Windows builds will be
>> broken until the 2.3.0 jar is removed.
>> 
>> Can you please remove C:\Users\jenkins\.ant\lib\ivy-2.3.0.jar from the
>> Windows VBOX?
>> 
>> Thanks.
>> 
>> --
>> Steve
>> www.lucidworks.com
>> 
>>> On Nov 2, 2017, at 8:10 PM, Policeman Jenkins Server
>>  wrote:
>>> 
>>> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/282/
>>> Java: 32bit/jdk1.8.0_144 -server -XX:+UseParallelGC
>>> 
>>> No tests ran.
>>> 
>>> Build Log:
>>> [...truncated 31 lines...]
>>> BUILD FAILED
>>> C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\build.xml:826: The
>> following error occurred while executing this line:
>>> C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\common-
>> build.xml:435: The following error occurred while executing this line:
>>> C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\common-
>> build.xml:446: Found disallowed Ivy jar(s): C:\Users\jenkins\.ant\lib\ivy-
>> 2.3.0.jar
>>> 
>>> Total time: 0 seconds
>>> Build step 'Invoke Ant' marked build as failure
>>> Archiving artifacts
>>> [WARNINGS] Skipping publisher since build result is FAILURE
>>> Recording test results
>>> ERROR: Step ‘Publish JUnit test result report’ failed: No test report files
>> were found. Configuration error?
>>> Email was triggered for: Failure - Any
>>> Sending email for trigger: Failure - Any
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[jira] [Commented] (SOLR-11409) A ref guide page on setting up solr on aws

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-11409:
-

Thank you Cassandra,

bq .At the top of the page, you write that the quick start is not meant for 
production systems, but in the Appendix you note that for production one should 
have a ZK ensemble of at least 3 nodes.

We can remove "Note for production one should have a ZK ensemble of at least 3 
nodes." as this qucik start is not meant for production and leave that bit of 
information to "Setting Zookeeper ensemble .", I understand it contradict 
the intro statement. I can remove that "bold" NOTE and upload new patch, let me 
know.

bq. Is it recommended to never deploy a production system to EC2? Or you could 
do it if you put an ensemble into place?

No, we can safely deploy production system on EC2 instances. The quick start is 
the base to understand how to establish a dev environment but need further 
pointers for production and this page doesn't serve that.

> A ref guide page on setting up solr on aws
> --
>
> Key: SOLR-11409
> URL: https://issues.apache.org/jira/browse/SOLR-11409
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Priority: Minor
> Attachments: SOLR-11409.patch, quick-start-aws-key.png, 
> quick-start-aws-security-1.png, quick-start-aws-security-2.png
>
>
> It will be nice if we have a dedicated page on installing solr on aws . 
> At the end we could even link to 
> http://lucene.apache.org/solr/guide/6_6/taking-solr-to-production.html



--
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-11595) optimize SolrIndexSearcher.localCollectionStatistics to use cached MultiFields

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11595:
-

bq. manually without constructing a MultiTerms object

Yes exactly; this is what I mean.  I'll throw up a patch -- probably on Monday.

> optimize SolrIndexSearcher.localCollectionStatistics to use cached MultiFields
> --
>
> Key: SOLR-11595
> URL: https://issues.apache.org/jira/browse/SOLR-11595
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 7.2
>
> Attachments: 
> SOLR_11595_optimize_SolrIndexSearcher_collectionStatistics.patch
>
>
> {{SolrIndexSearcher.localCollectionStatistics(field)}} simply calls Lucene's 
> {{IndexSearcher.collectionStatistics(field)}} which in turn calls 
> {{MultiFields.getTerms(reader, field)}}.  Profiling in an app with many 150 
> fields in the query shows that building the MultiTerms here is expensive.  
> Fortunately it turns out that Solr already has a cached instance via 
> {{SlowCompositeReaderWrapper}} (using MultiFields which has a 
> ConcurrentHashMap to the MultiTerms keyed by field String.
> Perhaps this should be improved on the Lucene side... not sure.  But here on 
> the Solr side, the solution is straight-forward.



--
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-11595) optimize SolrIndexSearcher.localCollectionStatistics to use cached MultiFields

[Adrien Grand (JIRA)]

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

Adrien Grand commented on SOLR-11595:
-

I was actually not thinking about caching the result but aggregating statistics 
manually without constructing a MultiTerms object. 

> optimize SolrIndexSearcher.localCollectionStatistics to use cached MultiFields
> --
>
> Key: SOLR-11595
> URL: https://issues.apache.org/jira/browse/SOLR-11595
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 7.2
>
> Attachments: 
> SOLR_11595_optimize_SolrIndexSearcher_collectionStatistics.patch
>
>
> {{SolrIndexSearcher.localCollectionStatistics(field)}} simply calls Lucene's 
> {{IndexSearcher.collectionStatistics(field)}} which in turn calls 
> {{MultiFields.getTerms(reader, field)}}.  Profiling in an app with many 150 
> fields in the query shows that building the MultiTerms here is expensive.  
> Fortunately it turns out that Solr already has a cached instance via 
> {{SlowCompositeReaderWrapper}} (using MultiFields which has a 
> ConcurrentHashMap to the MultiTerms keyed by field String.
> Perhaps this should be improved on the Lucene side... not sure.  But here on 
> the Solr side, the solution is straight-forward.



--
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 # 1412 - Still Unstable

[Apache Jenkins Server]

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

7 tests failed.
FAILED:  org.apache.lucene.index.TestIndexSorting.testRandom3

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([59AAA55DB4A2FE07]:0)


FAILED:  junit.framework.TestSuite.org.apache.lucene.index.TestIndexSorting

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([59AAA55DB4A2FE07]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsChaosMonkeySafeLeaderTest

Error Message:
6 threads leaked from SUITE scope at 
org.apache.solr.cloud.hdfs.HdfsChaosMonkeySafeLeaderTest: 1) 
Thread[id=32452, name=zkCallback-2840-thread-8, state=TIMED_WAITING, 
group=TGRP-HdfsChaosMonkeySafeLeaderTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
at java.lang.Thread.run(Thread.java:748)2) Thread[id=20234, 
name=StoppableIndexingThread-EventThread, state=WAITING, 
group=TGRP-HdfsChaosMonkeySafeLeaderTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501)
3) Thread[id=32453, name=zkCallback-2840-thread-9, state=TIMED_WAITING, 
group=TGRP-HdfsChaosMonkeySafeLeaderTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
at java.lang.Thread.run(Thread.java:748)4) Thread[id=20233, 
name=StoppableIndexingThread-SendThread(127.0.0.1:36935), state=TIMED_WAITING, 
group=TGRP-HdfsChaosMonkeySafeLeaderTest] at 
java.lang.Thread.sleep(Native Method) at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1051)5) 
Thread[id=32264, name=zkCallback-2840-thread-7, state=TIMED_WAITING, 
group=TGRP-HdfsChaosMonkeySafeLeaderTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
at java.lang.Thread.run(Thread.java:748)6) Thread[id=32239, 
name=zkCallback-2840-thread-6, state=TIMED_WAITING, 
group=TGRP-HdfsChaosMonkeySafeLeaderTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1

[jira] [Commented] (SOLR-11078) Solr query performance degradation since Solr 6.4.2

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11078:
-

@bidorbuy Thanks so much for sharing your real world results, and being willing 
to try some different configurations.

I think it would be most helpful to us here if we could focus on the same Solr 
version (say 7.1) and only vary the schema use of field types.  Because of the 
many references to 6.4.2 in your past comments, I'm not 100% clear if you have 
found Points vs Trie (with precisionStep>0) shows Points to win on _range 
queries_.  Based on what I know, I expect Points to be faster at this task, 
while also using less memory and disk.  If you are finding to the contrary, 
perhaps _some_ of your queries are actually doing lookups on these fields 
sometimes?  Or as Yonik pointed out, perhaps might have extremely low 
cardinality within the bounds of the range query sometimes (i.e. tight ranges 
matching few values)?

For now, I suggest using Trie with precisionStep=0 on fields you only use for 
lookups (no range queries).  Or use StrField if that suits you; it's almost the 
same.

> Solr query performance degradation since Solr 6.4.2
> ---
>
> Key: SOLR-11078
> URL: https://issues.apache.org/jira/browse/SOLR-11078
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search, Server
>Affects Versions: 6.6, 7.1
> Environment: * CentOS 7.3 (Linux zasolrm03 3.10.0-514.26.2.el7.x86_64 
> #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux)
> * Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
> * 4 CPU, 10GB RAM
> Running Solr 6.6.0 with the following JVM settings:
> java -server -Xms4G -Xmx4G -XX:NewRatio=3 -XX:SurvivorRatio=4 
> -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=8 -XX:+UseConcMarkSweepGC 
> -XX:+UseParNewGC -XX:ConcGCThreads=4 -XX:ParallelGCThreads=4 
> -XX:+CMSScavengeBeforeRemark -XX:PretenureSizeThreshold=64m 
> -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=50 
> -XX:CMSMaxAbortablePrecleanTime=6000 -XX:+CMSParallelRemarkEnabled 
> -XX:+ParallelRefProcEnabled -verbose:gc -XX:+PrintHeapAtGC 
> -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps 
> -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime 
> -Xloggc:/home/prodza/solrserver/../logs/solr_gc.log -XX:+UseGCLogFileRotation 
> -XX:NumberOfGCLogFiles=9 -XX:GCLogFileSize=20M 
> -Dsolr.log.dir=/home/prodza/solrserver/../logs -Djetty.port=8983 
> -DSTOP.PORT=7983 -DSTOP.KEY=solrrocks -Duser.timezone=SAST 
> -Djetty.home=/home/prodza/solrserver/server 
> -Dsolr.solr.home=/home/prodza/solrserver/../solr 
> -Dsolr.install.dir=/home/prodza/solrserver 
> -Dlog4j.configuration=file:/home/prodza/solrserver/../config/log4j.properties 
> -Xss256k -Xss256k -Dsolr.log.muteconsole 
> -XX:OnOutOfMemoryError=/home/prodza/solrserver/bin/oom_solr.sh 8983 
> /home/prodza/solrserver/../logs -jar start.jar --module=http
>Reporter: bidorbuy
>Priority: Major
> Attachments: compare-6.4.2-6.6.0.png, core-admin-tradesearch.png, 
> jvm-stats.png, schema.xml, screenshot-1.png, screenshot-2.png, 
> solr-6-4-2-schema.xml, solr-6-4-2-solrconfig.xml, solr-7-1-0-managed-schema, 
> solr-7-1-0-solrconfig.xml, solr-71-vs-64.png, solr-sample-warning-log.txt, 
> solr.in.sh, solrconfig.xml
>
>
> We are currently running 2 separate Solr servers - refer to screenshots:
> * zasolrm02 is running on Solr 6.4.2
> * zasolrm03 is running on Solr 6.6.0
> Both servers have the same OS / JVM configuration and are using their own 
> indexes. We round-robin load-balance through our Tomcats and notice that 
> Since Solr 6.4.2 performance has dropped. We have two indices per server 
> "searchsuggestions" and "tradesearch". There is a noticeable drop in 
> performance since Solr 6.4.2.
> I am not sure if this is perhaps related to metric collation or other 
> underlying changes. I am not sure if other high transaction users have 
> noticed similar issues.
> *1) zasolrm03 (6.6.0) is almost twice as slow on the tradesearch index:*
> !compare-6.4.2-6.6.0.png!
> *2) This is also visible in the searchsuggestion index:*
> !screenshot-1.png!
> *3) The Tradesearch index shows the biggest difference:*
> !screenshot-2.png!



--
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] [Updated] (SOLR-11601) solr.LatLonPointSpatialField : sorting by geodist fails

[Clemens Wyss (JIRA)]

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

Clemens Wyss updated SOLR-11601:

Description: 
Im switching my schemas from derprecated solr.LatLonType to 
solr.LatLonPointSpatialField.

Now my sortquery (which used to work with solr.LatLonType):

*sort=geodist(b4_location__geo_si,47.36667,8.55) asc*

raises the error

{color:red}*"sort param could not be parsed as a query, and is not a field that 
exists in the index: geodist(b4_location__geo_si,47.36667,8.55)"*{color}

Invoking sort using syntax 

{color:#14892c}sfield=b4_location__geo_si&pt=47.36667,8.55&sort=geodist() asc

works as expected though...{color}


  was:
Im switching my schemas from derprecated solr.LatLonType to 
solr.LatLonPointSpatialField.

Now my sortquery (which used to work with solr.LatLonType):

*sort=geodist(b4_location__geo_si,47.36667,8.55) asc*

raises the error

{color:red}*"sort param could not be parsed as a query, and is not a field that 
exists in the index: geodist(b4_location__geo_si,47.36667,8.55)"*{color}

Invoking sort by 

{color:#14892c}sfield=b4_location__geo_si&pt=47.36667,8.55&sort=geodist() asc

works as expected though...{color}



> solr.LatLonPointSpatialField : sorting by geodist fails
> ---
>
> Key: SOLR-11601
> URL: https://issues.apache.org/jira/browse/SOLR-11601
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Clemens Wyss
>Priority: Major
>
> Im switching my schemas from derprecated solr.LatLonType to 
> solr.LatLonPointSpatialField.
> Now my sortquery (which used to work with solr.LatLonType):
> *sort=geodist(b4_location__geo_si,47.36667,8.55) asc*
> raises the error
> {color:red}*"sort param could not be parsed as a query, and is not a field 
> that exists in the index: geodist(b4_location__geo_si,47.36667,8.55)"*{color}
> Invoking sort using syntax 
> {color:#14892c}sfield=b4_location__geo_si&pt=47.36667,8.55&sort=geodist() asc
> works as expected though...{color}



--
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] [Updated] (SOLR-11601) solr.LatLonPointSpatialField : sorting by geodist fails

[Clemens Wyss (JIRA)]

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

Clemens Wyss updated SOLR-11601:

Description: 
Im switching my schemas from derprecated solr.LatLonType to 
solr.LatLonPointSpatialField.

Now my sortquery (which used to work with solr.LatLonType):

*sort=geodist(b4_location__geo_si,47.36667,8.55) asc*

raises the error

{color:red}*"sort param could not be parsed as a query, and is not a field that 
exists in the index: geodist(b4_location__geo_si,47.36667,8.55)"*{color}

Invoking sort by 

{color:#14892c}sfield=b4_location__geo_si&pt=47.36667,8.55&sort=geodist() asc

works as expected though...{color}


  was:
Im switching my schemas from derprecated solr.LatLonType to 
solr.LatLonPointSpatialField. Now my sortquery (which used to work with 
solr.LatLonType):

sort=geodist(b4_location__geo_si,47.36667,8.55) asc

raises the error

"sort param could not be parsed as a query, and is not a field that exists in 
the index: geodist(b4_location__geo_si,47.36667,8.55)"

Invoking sort by 

sfield=b4_location__geo_si&pt=47.36667,8.55&sort=geodist() asc

works as expected though...



> solr.LatLonPointSpatialField : sorting by geodist fails
> ---
>
> Key: SOLR-11601
> URL: https://issues.apache.org/jira/browse/SOLR-11601
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Clemens Wyss
>Priority: Major
>
> Im switching my schemas from derprecated solr.LatLonType to 
> solr.LatLonPointSpatialField.
> Now my sortquery (which used to work with solr.LatLonType):
> *sort=geodist(b4_location__geo_si,47.36667,8.55) asc*
> raises the error
> {color:red}*"sort param could not be parsed as a query, and is not a field 
> that exists in the index: geodist(b4_location__geo_si,47.36667,8.55)"*{color}
> Invoking sort by 
> {color:#14892c}sfield=b4_location__geo_si&pt=47.36667,8.55&sort=geodist() asc
> works as expected though...{color}



--
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-11601) solr.LatLonPointSpatialField : sorting by geodist fails

[Clemens Wyss (JIRA)]

Clemens Wyss created SOLR-11601:
---

 Summary: solr.LatLonPointSpatialField : sorting by geodist fails
 Key: SOLR-11601
 URL: https://issues.apache.org/jira/browse/SOLR-11601
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.6
Reporter: Clemens Wyss
Priority: Major


Im switching my schemas from derprecated solr.LatLonType to 
solr.LatLonPointSpatialField. Now my sortquery (which used to work with 
solr.LatLonType):

sort=geodist(b4_location__geo_si,47.36667,8.55) asc

raises the error

"sort param could not be parsed as a query, and is not a field that exists in 
the index: geodist(b4_location__geo_si,47.36667,8.55)"

Invoking sort by 

sfield=b4_location__geo_si&pt=47.36667,8.55&sort=geodist() asc

works as expected though...




--
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-Linux (32bit/jdk1.8.0_144) - Build # 733 - Unstable!

[Policeman Jenkins Server]

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

4 tests failed.
FAILED:  org.apache.solr.cloud.BasicDistributedZkTest.test

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:40089/wqjo

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:40089/wqjo
at 
__randomizedtesting.SeedInfo.seed([A552B4586E403FF3:2D068B82C0BC520B]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
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:1096)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:183)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:200)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:315)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991)
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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest.testSimple

Error Message:
Waiting for collection testSimple1 null Live Nodes: [127.0.0.1:39388_solr, 
127.0.0.1:40952_solr] Last available state: 
DocCollection(testSimple1//collections/testSimple1/state.json/23)={   
"pullReplicas":"0",   "replicationFactor":"2",   "shards":{ "shard1":{  
 "range":"8000-",   "state":"active",   "replicas":{
 "core_node3":{   "core":"testSimple1_shard1_replica_n1",   
"base_url":"http://127.0.0.1:34157/solr";,   
"node_name":"127.0.0.1:34157_solr",   "state":"down",   
"type":"NRT"}, "core_node12":{   
"core":"testSimple1_shard1_replica_n11",   
"base_url":"http://127.0.0.1:39388/solr";,   
"node_name":"127.0.0.1:39388_solr",   "state":"active",   
"type":"NRT",   "leader":"true"}}}, "shard2":{   
"range":"0-7fff",   "state":"active",   "replicas":{ 
"core_node7":{   "core":"testSimple1_shard2_replica_n4",   
"base_url":"http://127.0.0.1:34157/solr";,   
"node_name":"127.0.0.1:34157_solr",   "state":"down",   
"type":"NRT"}, "core_node10":{   
"core":"testSimple1_shard2_replica_n9",   
"base_url":"http://127.0.0.1:39388/solr";,   
"node_name":"127.0.0.1:39388_solr",   "state":"active",   
"type":"NRT",   "leader":"true",   "router":{"name":"compositeId"}, 
  "maxShardsPerNode":"2",   "autoAddReplicas":"true",   "nrtReplicas":"2",   
"tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: Waiting for collection testSimple1
null
Live Nodes: [127.0.0.1:39388_solr, 127.0.0.1:40952_solr]
Last available state: 
DocCollection(testSimple1//collections/testSimple1/state.json/23)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{
"shard1":{
  "range":"8000-",
  "state":"active",
  "replicas":{
"core_node3":{
  "core":"testSimple1_shard1_replica_n1",
  "base_url":"http://127.0.0.1:34157/solr";,
  "node_name":"127.0.0.1:34157_solr",
  "state":"down",
  "type":"NRT"},
"core_node12":{
  "core":"testSimple1_shard1_replica_n11",
  "base_url":"http://127.0.0.1:39388/solr";,
  "node_name":"127.0.0.1:39388_solr",
  "state":"active",
  "type":"NRT",
  "leader":"true"}}},
"shard2":{
  "range":"0-7fff",
  "state":"active",
  "replicas":{
"core_node7":{
  "core":"testSimple1_shard2_replica_n4",
  "base_url":"http://127.0.0.1:34157/solr";,
  "node_name":"127.0.0.1:34157_solr",
  "state":"down",
  "type":"NRT"},
"core_node10":{
  "core":"testSimple1_shard2_replica_n9",
  "base_url":"http://127.0.0.1:39388/solr";,
  "node_name":"127.0.0.1:39388_solr",
  "state":"active",
  "type":"NRT",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"2",
  "autoAddReplicas":"true",
  "nrtReplicas":"2",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([9A9D8E2EDD50D0F5:A22EAAD0FAA30424]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269)
at 
org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest.testSimple(AutoAddReplicasIntegrationTest.java:124)
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)
 

[JENKINS] Lucene-Solr-Tests-7.x - Build # 215 - Still Failing

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.StressHdfsTest.test

Error Message:
Timeout occured while waiting response from server at: http://127.0.0.1:41848

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:41848
at 
__randomizedtesting.SeedInfo.seed([3A57765CB48D60AD:B20349861A710D55]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
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:1096)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:183)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:200)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:315)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991)
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(Stat