[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+132) - Build # 17649 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17649/
Java: 32bit/jdk-9-ea+132 -client -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.update.PeerSyncTest.test

Error Message:
expected: but was:

Stack Trace:
java.lang.AssertionError: expected: but was:
at 
__randomizedtesting.SeedInfo.seed([5C4D31BB32C6CAB5:D4190E619C3AA74D]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:147)
at org.apache.solr.update.PeerSyncTest.assertSync(PeerSyncTest.java:208)
at org.apache.solr.update.PeerSyncTest.test(PeerSyncTest.java:124)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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-MacOSX (64bit/jdk1.8.0) - Build # 3498 - Still unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3498/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.update.PeerSyncTest.test

Error Message:
expected: but was:

Stack Trace:
java.lang.AssertionError: expected: but was:
at 
__randomizedtesting.SeedInfo.seed([6CAFB999C547BA21:E4FB86436BBBD7D9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:147)
at org.apache.solr.update.PeerSyncTest.assertSync(PeerSyncTest.java:208)
at org.apache.solr.update.PeerSyncTest.test(PeerSyncTest.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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_102) - Build # 1553 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1553/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseG1GC

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

Error Message:
Captured an uncaught exception in thread: Thread[id=738, 
name=org.apache.solr.cloud.PeerSyncReplicationTest, state=RUNNABLE, 
group=TGRP-PeerSyncReplicationTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=738, 
name=org.apache.solr.cloud.PeerSyncReplicationTest, state=RUNNABLE, 
group=TGRP-PeerSyncReplicationTest]
Caused by: java.lang.RuntimeException: 
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:39906/collection1]
at __randomizedtesting.SeedInfo.seed([A330A410D1DAEE57]:0)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.lambda$indexInBackground$0(PeerSyncReplicationTest.java:185)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:39906/collection1]
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:774)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.indexDoc(PeerSyncReplicationTest.java:347)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.lambda$indexInBackground$0(PeerSyncReplicationTest.java:180)
... 1 more
Caused by: org.apache.solr.client.solrj.SolrServerException: No live 
SolrServers available to handle this 
request:[http://127.0.0.1:39906/collection1]
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:382)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:768)
... 8 more
Caused by: org.apache.solr.client.solrj.SolrServerException: Server refused 
connection at: http://127.0.0.1:39906/collection1
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:599)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:403)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:355)
... 9 more
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at 
org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:117)
at 
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:497)
... 13 more


FAILED:  org.apache.solr.update.PeerSyncTest.test

Error Message:
expected: but was:

Stack Trace:
java.lang.AssertionError: expected: but was:
at 
__randomizedtesting.SeedInfo.seed([A330A410D1DAEE57:2B649BCA7F2683AF]:0)
at org.junit.Assert.fail(Assert.java:93)
at 

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_102) - Build # 406 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/406/
Java: 32bit/jdk1.8.0_102 -server -XX:+UseG1GC

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

Error Message:
init query failed: 
{main(facet=true={!stats%3Dst2}pivot_d1,pivot_x_s,pivot_f1=13=6=50=true=count=1),extra(rows=0=*:*&_test_min=50&_test_miss=true&_test_sort=count)}:
 No live SolrServers available to handle this 
request:[http://127.0.0.1:59929/collection1, 
http://127.0.0.1:59954/collection1, http://127.0.0.1:59994/collection1, 
http://127.0.0.1:59917/collection1]

Stack Trace:
java.lang.RuntimeException: init query failed: 
{main(facet=true={!stats%3Dst2}pivot_d1,pivot_x_s,pivot_f1=13=6=50=true=count=1),extra(rows=0=*:*&_test_min=50&_test_miss=true&_test_sort=count)}:
 No live SolrServers available to handle this 
request:[http://127.0.0.1:59929/collection1, 
http://127.0.0.1:59954/collection1, http://127.0.0.1:59994/collection1, 
http://127.0.0.1:59917/collection1]
at 
__randomizedtesting.SeedInfo.seed([E3B7E958B83C5D51:6BE3D68216C030A9]:0)
at 
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:269)
at 
org.apache.solr.cloud.TestCloudPivotFacet.test(TestCloudPivotFacet.java:242)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

Re: [VOTE] Release Lucene/Solr 6.2.0 RC1

[Christian Moen]

+1
SUCCESS! [0:54:27.140402]

> On Aug 22, 2016, at 23:59, Adrien Grand  wrote:
> 
> +1
> SUCCESS! [4:06:37.981292]
> 
> Le lun. 22 août 2016 à 09:00, Noble Paul  > a écrit :
> I'm not sure if there is going to be a respin. SOLR-9310 is a
> worthwhile addition
> 
> On Mon, Aug 22, 2016 at 12:22 AM, Uwe Schindler  > wrote:
> > Hi,
> >
> > Thanks for testing on Linux, Steve (we chatted on IRC). I committed the new 
> > policy file change to master, 6.x and also 6.2 (but no respin needed, as 
> > this only fixes Jenkins).
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de 
> > eMail: u...@thetaphi.de 
> >
> >> -Original Message-
> >> From: Uwe Schindler [mailto:u...@thetaphi.de ]
> >> Sent: Sunday, August 21, 2016 6:45 PM
> >> To: dev@lucene.apache.org 
> >> Subject: RE: [VOTE] Release Lucene/Solr 6.2.0 RC1
> >>
> >> Oh, I tried it out, this works:
> >>
> >>   permission java.io.FilePermission "${tests.linedocsfile}", "read";
> >>
> >> But you have to be sure that the path is resolving correctly (if its 
> >> relative).
> >>
> >> I will do a few more tests and commit this to master and 6.x + reconfigure
> >> Jenkins Nightly to enable Security Manager again.
> >>
> >> Uwe
> >>
> >> -
> >> Uwe Schindler
> >> H.-H.-Meier-Allee 63, D-28213 Bremen
> >> http://www.thetaphi.de 
> >> eMail: u...@thetaphi.de 
> >>
> >> > -Original Message-
> >> > From: Uwe Schindler [mailto:u...@thetaphi.de ]
> >> > Sent: Sunday, August 21, 2016 6:37 PM
> >> > To: dev@lucene.apache.org 
> >> > Cc: 'Steve Rowe' >
> >> > Subject: RE: [VOTE] Release Lucene/Solr 6.2.0 RC1
> >> >
> >> > Hi Steve,
> >> >
> >> > I am planning to add support for another way to dynamically specify the
> >> > linedocsfile in the policy file, so it respects a linedocsfile outside 
> >> > the
> >> > checkout. Simply copypasting the ${tests.linedocsfile} property into the
> >> policy
> >> > file only works if the path is absolute, which is not guaranteed by the
> >> > sysprop...
> >> >
> >> > I will open an issue if I have an idea.
> >> >
> >> > Uwe
> >> >
> >> > -
> >> > Uwe Schindler
> >> > H.-H.-Meier-Allee 63, D-28213 Bremen
> >> > http://www.thetaphi.de 
> >> > eMail: u...@thetaphi.de 
> >> > > From: Steve Rowe [mailto:sar...@gmail.com ]
> >> > > Sent: Sunday, August 21, 2016 6:15 PM
> >> > > To: dev@lucene.apache.org 
> >> > > Subject: Re: [VOTE] Release Lucene/Solr 6.2.0 RC1
> >> > >
> >> > > +1
> >> > >
> >> > > Smoke tester is happy now that it’s friends with Ant 1.9: SUCCESS!
> >> > > [0:28:35.468036]
> >> > >
> >> > > and docs, javadocs and changes look good.
> >> > >
> >> > > FYI I had to remove the “tests.linedocsfile” sysprop from my
> >> > > ~/lucene.build.properties to mollify the security manager.
> >> > >
> >> > > --
> >> > > Steve
> >> > > www.lucidworks.com 
> >> > >
> >> > > > On Aug 21, 2016, at 4:48 AM, Michael McCandless
> >> > > > wrote:
> >> > > >
> >> > > > Duh, sorry, I forgot to push this fix to the smoke tester (to also 
> >> > > > accept
> >> ant
> >> > > 1.9.x).  I'll go do that!
> >> > > >
> >> > > > Mike McCandless
> >> > > >
> >> > > > http://blog.mikemccandless.com 
> >> > > >
> >> > > > On Sun, Aug 21, 2016 at 2:38 AM, Christian Moen  >> > > > >
> >> > wrote:
> >> > > > Hi,
> >> > > >
> >> > > > My smoke tester gives the same error as Steve's.
> >> > > >
> >> > > > Best,
> >> > > > Christian
> >> > > >
> >> > > > > On Aug 21, 2016, at 08:35, Steve Rowe  >> > > > > > wrote:
> >> > > > >
> >> > > > > Hi Mike,
> >> > > > >
> >> > > > > The branch_6_2 smoke tester is irritated with your choice of Ant:
> >> > > > >
> >> > > > > RuntimeError: JAR file
> >> > >
> >> >
> >> "/tmp/smoke_lucene_6.2.0_764d0f19151dbff6f5fcd9fc4b2682cf934590c5_1/
> >> > > unpack/lucene-6.2.0/codecs/lucene-codecs-6.2.0.jar" is missing "Ant-
> >> > > Version: Apache Ant 1.8" inside its META-INF/MANIFEST.MF
> >> > > > >
> >> > > > > And that file has:
> >> > > > >
> >> > > > >   Ant-Version: Apache Ant 1.9.7
> >> > > > >
> >> > > > > I saw a commit notification about addressing one aspect of that, 
> >> > > > > but I
> >> > > guess not the manifest aspect?
> >> > > > >
> >> > > > > --
> >> > > > > Steve
> >> > > > > www.lucidworks.com 
> >> > > > >
> >> > > > >> On Aug 20, 

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17648/
Java: 64bit/jdk1.8.0_102 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
Captured an uncaught exception in thread: Thread[id=4484, 
name=org.apache.solr.cloud.PeerSyncReplicationTest, state=RUNNABLE, 
group=TGRP-PeerSyncReplicationTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=4484, 
name=org.apache.solr.cloud.PeerSyncReplicationTest, state=RUNNABLE, 
group=TGRP-PeerSyncReplicationTest]
Caused by: java.lang.RuntimeException: 
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[https://127.0.0.1:35939/collection1]
at __randomizedtesting.SeedInfo.seed([5153A599FE881C77]:0)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.lambda$indexInBackground$0(PeerSyncReplicationTest.java:185)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[https://127.0.0.1:35939/collection1]
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:774)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.indexDoc(PeerSyncReplicationTest.java:347)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.lambda$indexInBackground$0(PeerSyncReplicationTest.java:180)
... 1 more
Caused by: org.apache.solr.client.solrj.SolrServerException: No live 
SolrServers available to handle this 
request:[https://127.0.0.1:35939/collection1]
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:392)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:768)
... 8 more
Caused by: org.apache.solr.client.solrj.SolrServerException: Server refused 
connection at: https://127.0.0.1:35939/collection1
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:615)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:365)
... 9 more
Caused by: org.apache.http.conn.HttpHostConnectException: Connect to 
127.0.0.1:35939 [/127.0.0.1] failed: Connection refused
at 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:151)
at 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
at 
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:513)
... 13 more
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at 

[jira] [Commented] (SOLR-9319) DELETEREPLICA should be able to accept just count and remove replicas intelligenty

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9319:
--

GitHub user nitingithub opened a pull request:

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

DELETEREPLICA should be able to accept just count and remove replicas 
intelligently

DELETEREPLICA should be able to accept just count and remove replicas 
intelligently
SOLR-9319

More details: https://issues.apache.org/jira/browse/SOLR-9319

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

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

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

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

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

This closes #70


commit 332e447f085e779e4b56ab0617bf095385e5ffae
Author: Nitin Sharma 
Date:   2016-08-23T02:44:39Z

DELETEREPLICA should be able to accept just count and remove replicas 
intelligenty
SOLR-9319




> DELETEREPLICA should be able to accept  just count and remove replicas 
> intelligenty
> ---
>
> Key: SOLR-9319
> URL: https://issues.apache.org/jira/browse/SOLR-9319
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: DeleteReplicaPatch.jpg, Delete_Replica_count_1.jpg, 
> Delete_Replica_invalid.jpg, Delete_Replica_with_only_1replica.jpg, 
> Delete_replica_count2.jpg, Delte_replica_after.jpg, Delte_replica_before.jpg, 
> Old_deletereplica_api_works.jpg, SOLR-9310.patch, SOLR-9319.patch, 
> SOLR-9319.patch, SOLR-9319.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] lucene-solr pull request #70: DELETEREPLICA should be able to accept just co...

[nitingithub]

GitHub user nitingithub opened a pull request:

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

DELETEREPLICA should be able to accept just count and remove replicas 
intelligently

DELETEREPLICA should be able to accept just count and remove replicas 
intelligently
SOLR-9319

More details: https://issues.apache.org/jira/browse/SOLR-9319

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

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

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

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

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

This closes #70


commit 332e447f085e779e4b56ab0617bf095385e5ffae
Author: Nitin Sharma 
Date:   2016-08-23T02:44:39Z

DELETEREPLICA should be able to accept just count and remove replicas 
intelligenty
SOLR-9319




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+132) - Build # 1552 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1552/
Java: 32bit/jdk-9-ea+132 -client -XX:+UseG1GC

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

Error Message:
Expected 2 of 3 replicas to be active but only found 1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica3","base_url":"http://127.0.0.1:38327/cx_","node_name":"127.0.0.1:38327_cx_","state":"active","leader":"true"}];
 clusterState: 
DocCollection(c8n_1x3_lf//collections/c8n_1x3_lf/state.json/19)={   
"replicationFactor":"3",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   "state":"down",   
"base_url":"http://127.0.0.1:34770/cx_;,   
"core":"c8n_1x3_lf_shard1_replica2",   
"node_name":"127.0.0.1:34770_cx_"}, "core_node2":{   
"core":"c8n_1x3_lf_shard1_replica1",   
"base_url":"http://127.0.0.1:35279/cx_;,   
"node_name":"127.0.0.1:35279_cx_",   "state":"down"}, 
"core_node3":{   "core":"c8n_1x3_lf_shard1_replica3",   
"base_url":"http://127.0.0.1:38327/cx_;,   
"node_name":"127.0.0.1:38327_cx_",   "state":"active",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"1",   "autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica3","base_url":"http://127.0.0.1:38327/cx_","node_name":"127.0.0.1:38327_cx_","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf//collections/c8n_1x3_lf/state.json/19)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "state":"down",
  "base_url":"http://127.0.0.1:34770/cx_;,
  "core":"c8n_1x3_lf_shard1_replica2",
  "node_name":"127.0.0.1:34770_cx_"},
"core_node2":{
  "core":"c8n_1x3_lf_shard1_replica1",
  "base_url":"http://127.0.0.1:35279/cx_;,
  "node_name":"127.0.0.1:35279_cx_",
  "state":"down"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica3",
  "base_url":"http://127.0.0.1:38327/cx_;,
  "node_name":"127.0.0.1:38327_cx_",
  "state":"active",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([D4AB4CA8CA973C36:5CFF7372646B51CE]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:168)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
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:367)
at 

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_102) - Build # 6070 - Still unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6070/
Java: 64bit/jdk1.8.0_102 -XX:-UseCompressedOops -XX:+UseParallelGC

4 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail

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

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<404>
at 
__randomizedtesting.SeedInfo.seed([6B269833028064D8:399AD19D21A7634]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.cancelDelegationToken(TestSolrCloudWithDelegationTokens.java:137)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail(TestSolrCloudWithDelegationTokens.java:282)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Comment Edited] (SOLR-9127) XLSX response writer - do we want it?

[Tony Moriarty (JIRA)]

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

Tony Moriarty edited comment on SOLR-9127 at 8/23/16 1:01 AM:
--

OK integrated. PR ready for review again. Update to the documentation (changed 
the solrconfig attribute names too):
{quote}
Column Width and mapping of metadata field names to nice names is configured 
for the responsewriter; this can be done in the solrconfig or through request 
params colname.foo and colwidth.foo.



8
128
...


Product ID
Product Name
...



{quote}

But on review i've noticed Jan's older suggestion of using field request 
parameters ie "f.id.xlsx.colname=Product ID" to do the renaming. Should I 
update it to use field params? 


was (Author: desultir):
OK integrated. PR ready for review again. Update to the documentation (changed 
the solrconfig attribute names too):
{quote}
Column Width and mapping of metadata field names to nice names is configured 
for the responsewriter; this can be done in the solrconfig or through request 
params colname.foo and colwidth.foo.



8
128
...


Product ID
Product Name
...



{/quote}

But on review i've noticed Jan's older suggestion of using field request 
parameters ie "f.id.xlsx.colname=Product ID" to do the renaming. Should I 
update it to use field params? 

> XLSX response writer - do we want it?
> -
>
> Key: SOLR-9127
> URL: https://issues.apache.org/jira/browse/SOLR-9127
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Reporter: Tony Moriarty
>Priority: Minor
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-9127.patch
>
>
> I recently open sourced an XLSX response writer based on solr 4.6 and apache 
> poi.
> https://github.com/desultir/SolrXLSXResponseWriter
> Is this something the community would be interested in bringing into the solr 
> codebase? I'm willing to put the work into porting it to solr5 and solr6 if 
> the community is interested, happy to leave it as a plugin otherwise.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-9127) XLSX response writer - do we want it?

[Tony Moriarty (JIRA)]

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

Tony Moriarty edited comment on SOLR-9127 at 8/23/16 1:00 AM:
--

OK integrated. PR ready for review again. Update to the documentation (changed 
the solrconfig attribute names too):
{quote}
Column Width and mapping of metadata field names to nice names is configured 
for the responsewriter; this can be done in the solrconfig or through request 
params colname.foo and colwidth.foo.



8
128
...


Product ID
Product Name
...



{/quote}

But on review i've noticed Jan's older suggestion of using field request 
parameters ie "f.id.xlsx.colname=Product ID" to do the renaming. Should I 
update it to use field params? 


was (Author: desultir):
OK integrated. PR ready for review again. Update to the documentation (changed 
the solrconfig attribute names too):
{quote}
Column Width and mapping of metadata field names to nice names is configured 
for the responsewriter; this can be done in the solrconfig or through request 
params colname.foo and colwidth.foo.


8
128
...


Product ID
Product Name
...


{/quote}

But on review i've noticed Jan's older suggestion of using field request 
parameters ie "f.id.xlsx.colname=Product ID" to do the renaming. Should I 
update it to use field params? 

> XLSX response writer - do we want it?
> -
>
> Key: SOLR-9127
> URL: https://issues.apache.org/jira/browse/SOLR-9127
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Reporter: Tony Moriarty
>Priority: Minor
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-9127.patch
>
>
> I recently open sourced an XLSX response writer based on solr 4.6 and apache 
> poi.
> https://github.com/desultir/SolrXLSXResponseWriter
> Is this something the community would be interested in bringing into the solr 
> codebase? I'm willing to put the work into porting it to solr5 and solr6 if 
> the community is interested, happy to leave it as a plugin otherwise.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9127) XLSX response writer - do we want it?

[Tony Moriarty (JIRA)]

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

Tony Moriarty commented on SOLR-9127:
-

OK integrated. PR ready for review again. Update to the documentation (changed 
the solrconfig attribute names too):
{quote}
Column Width and mapping of metadata field names to nice names is configured 
for the responsewriter; this can be done in the solrconfig or through request 
params colname.foo and colwidth.foo.


8
128
...


Product ID
Product Name
...


{/quote}

But on review i've noticed Jan's older suggestion of using field request 
parameters ie "f.id.xlsx.colname=Product ID" to do the renaming. Should I 
update it to use field params? 

> XLSX response writer - do we want it?
> -
>
> Key: SOLR-9127
> URL: https://issues.apache.org/jira/browse/SOLR-9127
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Reporter: Tony Moriarty
>Priority: Minor
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-9127.patch
>
>
> I recently open sourced an XLSX response writer based on solr 4.6 and apache 
> poi.
> https://github.com/desultir/SolrXLSXResponseWriter
> Is this something the community would be interested in bringing into the solr 
> codebase? I'm willing to put the work into porting it to solr5 and solr6 if 
> the community is interested, happy to leave it as a plugin otherwise.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
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 (32bit/jdk-9-ea+132) - Build # 17647 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17647/
Java: 32bit/jdk-9-ea+132 -server -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail

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

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<404>
at 
__randomizedtesting.SeedInfo.seed([579B561326DEB974:3F246339F644AB98]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.cancelDelegationToken(TestSolrCloudWithDelegationTokens.java:137)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail(TestSolrCloudWithDelegationTokens.java:282)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)

[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 348 - Still unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/348/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

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

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:40476/zne/hv/forceleader_test_collection_shard1_replica1]

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: No live 
SolrServers available to handle this 
request:[http://127.0.0.1:40476/zne/hv/forceleader_test_collection_shard1_replica1]
at 
__randomizedtesting.SeedInfo.seed([3BB66D88767F5B59:DD2159484FFDA238]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:760)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.ForceLeaderTest.sendDoc(ForceLeaderTest.java:424)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:131)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Commented] (SOLR-9284) The HDFS BlockDirectoryCache should not let it's keysToRelease or names maps grow indefinitely.

[Michael Sun (JIRA)]

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

Michael Sun commented on SOLR-9284:
---

Thanks [~markrmil...@gmail.com] for patch. Here is some of my thoughts.

1. In BlockDirectoryCache, the map between name and integer is changed to use 
Caffeine cache without setting up removal listener. I am not sure if it's 
correct. If Caffeine cache removes a name in cache, underlying Block Cache 
needs to delete all blocks related to that name. 
2. There are a few occurrences of System.out.println() in BlockDirectoryCache. 
It's better to use log.




> The HDFS BlockDirectoryCache should not let it's keysToRelease or names maps 
> grow indefinitely.
> ---
>
> Key: SOLR-9284
> URL: https://issues.apache.org/jira/browse/SOLR-9284
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: hdfs
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9284.patch
>
>
> https://issues.apache.org/jira/browse/SOLR-9284



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+132) - Build # 1551 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1551/
Java: 32bit/jdk-9-ea+132 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.update.PeerSyncTest.test

Error Message:
expected: but was:

Stack Trace:
java.lang.AssertionError: expected: but was:
at 
__randomizedtesting.SeedInfo.seed([AC900409C6D9FF45:24C43BD3682592BD]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:147)
at org.apache.solr.update.PeerSyncTest.assertSync(PeerSyncTest.java:208)
at org.apache.solr.update.PeerSyncTest.test(PeerSyncTest.java:124)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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] [Comment Edited] (SOLR-9319) DELETEREPLICA should be able to accept just count and remove replicas intelligenty

[Nitin Sharma (JIRA)]

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

Nitin Sharma edited comment on SOLR-9319 at 8/22/16 11:05 PM:
--

[~noble.paul] Rebased on master. Ran E2e Tests and unit tests. 


was (Author: nitin.sharma):
Rebased on master. Ran E2e Tests and unit tests

> DELETEREPLICA should be able to accept  just count and remove replicas 
> intelligenty
> ---
>
> Key: SOLR-9319
> URL: https://issues.apache.org/jira/browse/SOLR-9319
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: DeleteReplicaPatch.jpg, Delete_Replica_count_1.jpg, 
> Delete_Replica_invalid.jpg, Delete_Replica_with_only_1replica.jpg, 
> Delete_replica_count2.jpg, Delte_replica_after.jpg, Delte_replica_before.jpg, 
> Old_deletereplica_api_works.jpg, SOLR-9310.patch, SOLR-9319.patch, 
> SOLR-9319.patch, SOLR-9319.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9319) DELETEREPLICA should be able to accept just count and remove replicas intelligenty

[Nitin Sharma (JIRA)]

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

Nitin Sharma updated SOLR-9319:
---
Attachment: SOLR-9319.patch

Rebased on master. Ran E2e Tests and unit tests

> DELETEREPLICA should be able to accept  just count and remove replicas 
> intelligenty
> ---
>
> Key: SOLR-9319
> URL: https://issues.apache.org/jira/browse/SOLR-9319
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: DeleteReplicaPatch.jpg, Delete_Replica_count_1.jpg, 
> Delete_Replica_invalid.jpg, Delete_Replica_with_only_1replica.jpg, 
> Delete_replica_count2.jpg, Delte_replica_after.jpg, Delte_replica_before.jpg, 
> Old_deletereplica_api_works.jpg, SOLR-9310.patch, SOLR-9319.patch, 
> SOLR-9319.patch, SOLR-9319.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Issue Comment Deleted] (SOLR-9241) Rebalance API for SolrCloud

[Nitin Sharma (JIRA)]

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

Nitin Sharma updated SOLR-9241:
---
Comment: was deleted

(was: Rebased on top of master. Ran tests both unit and E2e)

> Rebalance API for SolrCloud
> ---
>
> Key: SOLR-9241
> URL: https://issues.apache.org/jira/browse/SOLR-9241
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Affects Versions: 6.1
> Environment: Ubuntu, Mac OsX
>Reporter: Nitin Sharma
>  Labels: Cluster, SolrCloud
> Fix For: 6.1
>
> Attachments: Redistribute_After.jpeg, Redistribute_Before.jpeg, 
> Redistribute_call.jpeg, Replace_After.jpeg, Replace_Before.jpeg, 
> Replace_Call.jpeg, SOLR-9241-4.6.patch, SOLR-9241-6.1.patch
>
>   Original Estimate: 2,016h
>  Remaining Estimate: 2,016h
>
> This is the v1 of the patch for Solrcloud Rebalance api (as described in 
> http://engineering.bloomreach.com/solrcloud-rebalance-api/) , built at 
> Bloomreach by Nitin Sharma and Suruchi Shah. The goal of the API  is to 
> provide a zero downtime mechanism to perform data manipulation and  efficient 
> core allocation in solrcloud. This API was envisioned to be the base layer 
> that enables Solrcloud to be an auto scaling platform. (and work in unison 
> with other complementing monitoring and scaling features).
> Patch Status:
> ===
> The patch is work in progress and incremental. We have done a few rounds of 
> code clean up. We wanted to get the patch going first to get initial feed 
> back.  We will continue to work on making it more open source friendly and 
> easily testable.
>  Deployment Status:
> 
> The platform is deployed in production at bloomreach and has been battle 
> tested for large scale load. (millions of documents and hundreds of 
> collections).
>  Internals:
> =
> The internals of the API and performance : 
> http://engineering.bloomreach.com/solrcloud-rebalance-api/
> It is built on top of the admin collections API as an action (with various 
> flavors). At a high level, the rebalance api provides 2 constructs:
> Scaling Strategy:  Decides how to move the data.  Every flavor has multiple 
> options which can be reviewed in the api spec.
> Re-distribute  - Move around data in the cluster based on capacity/allocation.
> Auto Shard  - Dynamically shard a collection to any size.
> Smart Merge - Distributed Mode - Helps merging data from a larger shard setup 
> into smaller one.  (the source should be divisible by destination)
> Scale up -  Add replicas on the fly
> Scale Down - Remove replicas on the fly
> Allocation Strategy:  Decides where to put the data.  (Nodes with least 
> cores, Nodes that do not have this collection etc). Custom implementations 
> can be built on top as well. One other example is Availability Zone aware. 
> Distribute data such that every replica is placed on different availability 
> zone to support HA.
>  Detailed API Spec:
> 
>   https://github.com/bloomreach/solrcloud-rebalance-api
>  Contributors:
> =
>   Nitin Sharma
>   Suruchi Shah
>  Questions/Comments:
> =
>   You can reach me at nitin.sha...@bloomreach.com



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-9241) Rebalance API for SolrCloud

[Nitin Sharma (JIRA)]

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

Nitin Sharma edited comment on SOLR-9241 at 8/22/16 11:03 PM:
--

Rebased on top of master. Ran tests both unit and E2e


was (Author: nitin.sharma):
Rebased on top of master

> Rebalance API for SolrCloud
> ---
>
> Key: SOLR-9241
> URL: https://issues.apache.org/jira/browse/SOLR-9241
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Affects Versions: 6.1
> Environment: Ubuntu, Mac OsX
>Reporter: Nitin Sharma
>  Labels: Cluster, SolrCloud
> Fix For: 6.1
>
> Attachments: Redistribute_After.jpeg, Redistribute_Before.jpeg, 
> Redistribute_call.jpeg, Replace_After.jpeg, Replace_Before.jpeg, 
> Replace_Call.jpeg, SOLR-9241-4.6.patch, SOLR-9241-6.1.patch
>
>   Original Estimate: 2,016h
>  Remaining Estimate: 2,016h
>
> This is the v1 of the patch for Solrcloud Rebalance api (as described in 
> http://engineering.bloomreach.com/solrcloud-rebalance-api/) , built at 
> Bloomreach by Nitin Sharma and Suruchi Shah. The goal of the API  is to 
> provide a zero downtime mechanism to perform data manipulation and  efficient 
> core allocation in solrcloud. This API was envisioned to be the base layer 
> that enables Solrcloud to be an auto scaling platform. (and work in unison 
> with other complementing monitoring and scaling features).
> Patch Status:
> ===
> The patch is work in progress and incremental. We have done a few rounds of 
> code clean up. We wanted to get the patch going first to get initial feed 
> back.  We will continue to work on making it more open source friendly and 
> easily testable.
>  Deployment Status:
> 
> The platform is deployed in production at bloomreach and has been battle 
> tested for large scale load. (millions of documents and hundreds of 
> collections).
>  Internals:
> =
> The internals of the API and performance : 
> http://engineering.bloomreach.com/solrcloud-rebalance-api/
> It is built on top of the admin collections API as an action (with various 
> flavors). At a high level, the rebalance api provides 2 constructs:
> Scaling Strategy:  Decides how to move the data.  Every flavor has multiple 
> options which can be reviewed in the api spec.
> Re-distribute  - Move around data in the cluster based on capacity/allocation.
> Auto Shard  - Dynamically shard a collection to any size.
> Smart Merge - Distributed Mode - Helps merging data from a larger shard setup 
> into smaller one.  (the source should be divisible by destination)
> Scale up -  Add replicas on the fly
> Scale Down - Remove replicas on the fly
> Allocation Strategy:  Decides where to put the data.  (Nodes with least 
> cores, Nodes that do not have this collection etc). Custom implementations 
> can be built on top as well. One other example is Availability Zone aware. 
> Distribute data such that every replica is placed on different availability 
> zone to support HA.
>  Detailed API Spec:
> 
>   https://github.com/bloomreach/solrcloud-rebalance-api
>  Contributors:
> =
>   Nitin Sharma
>   Suruchi Shah
>  Questions/Comments:
> =
>   You can reach me at nitin.sha...@bloomreach.com



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9241) Rebalance API for SolrCloud

[Nitin Sharma (JIRA)]

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

Nitin Sharma updated SOLR-9241:
---
Attachment: SOLR-9319.patch

Rebased on top of master

> Rebalance API for SolrCloud
> ---
>
> Key: SOLR-9241
> URL: https://issues.apache.org/jira/browse/SOLR-9241
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Affects Versions: 6.1
> Environment: Ubuntu, Mac OsX
>Reporter: Nitin Sharma
>  Labels: Cluster, SolrCloud
> Fix For: 6.1
>
> Attachments: Redistribute_After.jpeg, Redistribute_Before.jpeg, 
> Redistribute_call.jpeg, Replace_After.jpeg, Replace_Before.jpeg, 
> Replace_Call.jpeg, SOLR-9241-4.6.patch, SOLR-9241-6.1.patch
>
>   Original Estimate: 2,016h
>  Remaining Estimate: 2,016h
>
> This is the v1 of the patch for Solrcloud Rebalance api (as described in 
> http://engineering.bloomreach.com/solrcloud-rebalance-api/) , built at 
> Bloomreach by Nitin Sharma and Suruchi Shah. The goal of the API  is to 
> provide a zero downtime mechanism to perform data manipulation and  efficient 
> core allocation in solrcloud. This API was envisioned to be the base layer 
> that enables Solrcloud to be an auto scaling platform. (and work in unison 
> with other complementing monitoring and scaling features).
> Patch Status:
> ===
> The patch is work in progress and incremental. We have done a few rounds of 
> code clean up. We wanted to get the patch going first to get initial feed 
> back.  We will continue to work on making it more open source friendly and 
> easily testable.
>  Deployment Status:
> 
> The platform is deployed in production at bloomreach and has been battle 
> tested for large scale load. (millions of documents and hundreds of 
> collections).
>  Internals:
> =
> The internals of the API and performance : 
> http://engineering.bloomreach.com/solrcloud-rebalance-api/
> It is built on top of the admin collections API as an action (with various 
> flavors). At a high level, the rebalance api provides 2 constructs:
> Scaling Strategy:  Decides how to move the data.  Every flavor has multiple 
> options which can be reviewed in the api spec.
> Re-distribute  - Move around data in the cluster based on capacity/allocation.
> Auto Shard  - Dynamically shard a collection to any size.
> Smart Merge - Distributed Mode - Helps merging data from a larger shard setup 
> into smaller one.  (the source should be divisible by destination)
> Scale up -  Add replicas on the fly
> Scale Down - Remove replicas on the fly
> Allocation Strategy:  Decides where to put the data.  (Nodes with least 
> cores, Nodes that do not have this collection etc). Custom implementations 
> can be built on top as well. One other example is Availability Zone aware. 
> Distribute data such that every replica is placed on different availability 
> zone to support HA.
>  Detailed API Spec:
> 
>   https://github.com/bloomreach/solrcloud-rebalance-api
>  Contributors:
> =
>   Nitin Sharma
>   Suruchi Shah
>  Questions/Comments:
> =
>   You can reach me at nitin.sha...@bloomreach.com



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9241) Rebalance API for SolrCloud

[Nitin Sharma (JIRA)]

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

Nitin Sharma updated SOLR-9241:
---
Attachment: (was: SOLR-9319.patch)

> Rebalance API for SolrCloud
> ---
>
> Key: SOLR-9241
> URL: https://issues.apache.org/jira/browse/SOLR-9241
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Affects Versions: 6.1
> Environment: Ubuntu, Mac OsX
>Reporter: Nitin Sharma
>  Labels: Cluster, SolrCloud
> Fix For: 6.1
>
> Attachments: Redistribute_After.jpeg, Redistribute_Before.jpeg, 
> Redistribute_call.jpeg, Replace_After.jpeg, Replace_Before.jpeg, 
> Replace_Call.jpeg, SOLR-9241-4.6.patch, SOLR-9241-6.1.patch
>
>   Original Estimate: 2,016h
>  Remaining Estimate: 2,016h
>
> This is the v1 of the patch for Solrcloud Rebalance api (as described in 
> http://engineering.bloomreach.com/solrcloud-rebalance-api/) , built at 
> Bloomreach by Nitin Sharma and Suruchi Shah. The goal of the API  is to 
> provide a zero downtime mechanism to perform data manipulation and  efficient 
> core allocation in solrcloud. This API was envisioned to be the base layer 
> that enables Solrcloud to be an auto scaling platform. (and work in unison 
> with other complementing monitoring and scaling features).
> Patch Status:
> ===
> The patch is work in progress and incremental. We have done a few rounds of 
> code clean up. We wanted to get the patch going first to get initial feed 
> back.  We will continue to work on making it more open source friendly and 
> easily testable.
>  Deployment Status:
> 
> The platform is deployed in production at bloomreach and has been battle 
> tested for large scale load. (millions of documents and hundreds of 
> collections).
>  Internals:
> =
> The internals of the API and performance : 
> http://engineering.bloomreach.com/solrcloud-rebalance-api/
> It is built on top of the admin collections API as an action (with various 
> flavors). At a high level, the rebalance api provides 2 constructs:
> Scaling Strategy:  Decides how to move the data.  Every flavor has multiple 
> options which can be reviewed in the api spec.
> Re-distribute  - Move around data in the cluster based on capacity/allocation.
> Auto Shard  - Dynamically shard a collection to any size.
> Smart Merge - Distributed Mode - Helps merging data from a larger shard setup 
> into smaller one.  (the source should be divisible by destination)
> Scale up -  Add replicas on the fly
> Scale Down - Remove replicas on the fly
> Allocation Strategy:  Decides where to put the data.  (Nodes with least 
> cores, Nodes that do not have this collection etc). Custom implementations 
> can be built on top as well. One other example is Availability Zone aware. 
> Distribute data such that every replica is placed on different availability 
> zone to support HA.
>  Detailed API Spec:
> 
>   https://github.com/bloomreach/solrcloud-rebalance-api
>  Contributors:
> =
>   Nitin Sharma
>   Suruchi Shah
>  Questions/Comments:
> =
>   You can reach me at nitin.sha...@bloomreach.com



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
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 # 801 - Failure!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.update.PeerSyncTest.test

Error Message:
expected: but was:

Stack Trace:
java.lang.AssertionError: expected: but was:
at 
__randomizedtesting.SeedInfo.seed([5358A459414BEBE2:DB0C9B83EFB7861A]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:147)
at org.apache.solr.update.PeerSyncTest.assertSync(PeerSyncTest.java:208)
at org.apache.solr.update.PeerSyncTest.test(PeerSyncTest.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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17646/
Java: 64bit/jdk-9-ea+132 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.update.PeerSyncTest.test

Error Message:
expected: but was:

Stack Trace:
java.lang.AssertionError: expected: but was:
at 
__randomizedtesting.SeedInfo.seed([4F2F4FE3E9121B6C:C77B703947EE7694]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:147)
at org.apache.solr.update.PeerSyncTest.assertSync(PeerSyncTest.java:208)
at org.apache.solr.update.PeerSyncTest.test(PeerSyncTest.java:124)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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-6.x-Linux (32bit/jdk1.8.0_102) - Build # 1550 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1550/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.update.PeerSyncTest.test

Error Message:
expected: but was:

Stack Trace:
java.lang.AssertionError: expected: but was:
at 
__randomizedtesting.SeedInfo.seed([38B39A1F08C5E6C4:B0E7A5C5A6398B3C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:147)
at org.apache.solr.update.PeerSyncTest.assertSync(PeerSyncTest.java:208)
at org.apache.solr.update.PeerSyncTest.test(PeerSyncTest.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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 365 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/365/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.update.PeerSyncTest.test

Error Message:
expected: but was:

Stack Trace:
java.lang.AssertionError: expected: but was:
at 
__randomizedtesting.SeedInfo.seed([B41EA980CE793448:3C4A965A608559B0]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:147)
at org.apache.solr.update.PeerSyncTest.assertSync(PeerSyncTest.java:208)
at org.apache.solr.update.PeerSyncTest.test(PeerSyncTest.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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

Peer sync and overlapping "windows" heuristic may be causing unnecessary full syncs?

[Erick Erickson]

Looking at the peer sync code and I don't quite understand the
condition where we report " Our versions are too old." (about line 498
in PeerySync.java, 6x).

Note that the "in the field" version is 5.3.1, but the code looks the
same in 6.x.

I get that we're testing the overlap between the versions we have and
our peer has. But how was the 20% overlap number arrived at? What is
it intended to guarantee? And in a case where where the requested
number of updates is > the size of the returned list, is it valid to
return true if there is _any_ overlap?


Why do I care? I'm seeing a case in the field where a very large
document exceeds the timeout even though the document successfully
indexes on the follower, it just takes a while.  The Solr node is up
and accepting more updates etc. No updates have actually been missed
AFAICT.

So the leader is telling the follower to sync due to the timeout. The
follower fails the test above and then goes into full sync
unnecessarily. Since this is a very large index this takes a very long
time, strains the system and the problem can cascade.

I'm wondering if this test can be relaxed when the versions list
returned from the peer is smaller than requested to not fail if there
is any overlap. This feels like an incomplete fix though, because I'm
taking it on faith that if the list returned == numRecordsToKeep, then
this test wouldn't be as likely to be tripped. But there's no
guarantee there so a special test in this case would just kick the can
down the road I think.

Can we do a different test perhaps (and I'm really reaching here into
unfamiliar code so this may be all wet)? Let's say the leader gets a
timeout. Would it be possible to rather than do a full peer sync have
the leader ask the follower "Hey, I sent you these versions and you
timed out, do you really have them or not?"? And if the follower was
still processing them not have to do any peer sync at all. Assuming we
could guarantee that the doc was in the replicas tlog when answering,
would that guarantee data integrity?

I can raise a JIRA if any of this makes sense.

Erick

-
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-9-ea+132) - Build # 17645 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17645/
Java: 64bit/jdk-9-ea+132 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.update.PeerSyncTest.test

Error Message:
expected: but was:

Stack Trace:
java.lang.AssertionError: expected: but was:
at 
__randomizedtesting.SeedInfo.seed([118F37547402920B:99DB088EDAFEFFF3]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:147)
at org.apache.solr.update.PeerSyncTest.assertSync(PeerSyncTest.java:208)
at org.apache.solr.update.PeerSyncTest.test(PeerSyncTest.java:124)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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-MacOSX (64bit/jdk1.8.0) - Build # 3497 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3497/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.common.cloud.TestCollectionStateWatchers.testWatchesWorkForStateFormat1

Error Message:
CollectionStateWatcher not notified of stateformat=1 collection creation

Stack Trace:
java.lang.AssertionError: CollectionStateWatcher not notified of stateformat=1 
collection creation
at 
__randomizedtesting.SeedInfo.seed([B6C060014BE61C73:D1077CEFBF5E38D2]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.common.cloud.TestCollectionStateWatchers.testWatchesWorkForStateFormat1(TestCollectionStateWatchers.java:290)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 13001 lines...]
   [junit4] Suite: org.apache.solr.common.cloud.TestCollectionStateWatchers
   [junit4]   2> 

[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_102) - Build # 1549 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1549/
Java: 64bit/jdk1.8.0_102 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:34390/c8n_1x3_lf_shard1_replica2]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:34390/c8n_1x3_lf_shard1_replica2]
at 
__randomizedtesting.SeedInfo.seed([38B0CFCDC162685F:B0E4F0176F9E05A7]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:774)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:592)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:578)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:174)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[jira] [Updated] (SOLR-9427) TestReplicationHandler.testRateLimitedReplication() failure

[Christine Poerschke (JIRA)]

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

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

Attaching proposed patch (against master) to increase timing precision for the 
test and to include the actual and expected values in the assertTrue's 
description.

> TestReplicationHandler.testRateLimitedReplication() failure
> ---
>
> Key: SOLR-9427
> URL: https://issues.apache.org/jira/browse/SOLR-9427
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-9427.patch
>
>
> My Jenkins found a branch_6x seed (reproduces for me but only if I remove 
> {{-Dtests.method=testRateLimitedReplication}} from the cmdline):
> {noformat}
> Checking out Revision 44df5b60266549e410b7691ebf49583d7370c0e3 
> (refs/remotes/origin/branch_6x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestReplicationHandler -Dtests.method=testRateLimitedReplication 
> -Dtests.seed=8D4745BDBC59A3E3 -Dtests.slow=true -Dtests.locale=fi-FI 
> -Dtests.timezone=America/Montevideo -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 15.9s J11 | 
> TestReplicationHandler.testRateLimitedReplication <<<
>[junit4]> Throwable #1: java.lang.AssertionError
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([8D4745BDBC59A3E3:BD33048B3EB220E]:0)
>[junit4]>  at 
> org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication(TestReplicationHandler.java:1410)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[ASF subversion and git services (JIRA)]

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

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

Commit 0bdbbbfd52a95e83ce3827161852dbccdd618f5b in lucene-solr's branch 
refs/heads/branch_6x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0bdbbbf ]

SOLR-9310: fixing concurrency issue and taking care of negative versions


> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Fix For: trunk, 6.3
>
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, 
> SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Pushkar Raste (JIRA)]

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

Pushkar Raste commented on SOLR-9310:
-

I tried that, but since `IndexFingerprint.getFingerprint()` can throw an 
exception, implementation using `computeIfAbsent` looked too ugly to use it.

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Fix For: trunk, 6.3
>
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, 
> SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+132) - Build # 17644 - Unstable!

[Steve Rowe]

This reproduces for me on Linux with Oracle JDK 1.8.0_77

> On Aug 22, 2016, at 1:40 PM, Policeman Jenkins Server  
> wrote:
> 
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17644/
> Java: 32bit/jdk-9-ea+132 -server -XX:+UseParallelGC
> 
> 1 tests failed.
> FAILED:  org.apache.lucene.index.TestAllFilesCheckIndexHeader.test
> 
> Error Message:
> file "_e.tvx" was already written to
> 
> Stack Trace:
> java.io.IOException: file "_e.tvx" was already written to
>   at 
> __randomizedtesting.SeedInfo.seed([8133F5B315A4BBBA:967CA69BB58D642]:0)
>   at 
> org.apache.lucene.store.MockDirectoryWrapper.createOutput(MockDirectoryWrapper.java:654)
>   at 
> org.apache.lucene.index.TestAllFilesCheckIndexHeader.checkOneFile(TestAllFilesCheckIndexHeader.java:106)
>   at 
> org.apache.lucene.index.TestAllFilesCheckIndexHeader.checkIndexHeader(TestAllFilesCheckIndexHeader.java:81)
>   at 
> org.apache.lucene.index.TestAllFilesCheckIndexHeader.test(TestAllFilesCheckIndexHeader.java:74)
>   at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
> Method)
>   at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
>   at 
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
>   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:367)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
>   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:367)
>   at java.lang.Thread.run(java.base@9-ea/Thread.java:843)
> 
> 
> 
> 
> Build Log:
> [...truncated 467 lines...]
>   [junit4] 

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9310:


I see the double-check locking pattern there... I believe 
ConcurrentHashMap.computeIfAbsent would be perfect in this case?

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Fix For: trunk, 6.3
>
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, 
> SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[ASF subversion and git services (JIRA)]

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

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

Commit 37ae065591772172dbd44cde4c952d7b56fc8803 in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=37ae065 ]

SOLR-9310: fixing concurrency issue and taking care of negative versions


> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Fix For: trunk, 6.3
>
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, 
> SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
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 (32bit/jdk-9-ea+132) - Build # 17644 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17644/
Java: 32bit/jdk-9-ea+132 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.lucene.index.TestAllFilesCheckIndexHeader.test

Error Message:
file "_e.tvx" was already written to

Stack Trace:
java.io.IOException: file "_e.tvx" was already written to
at 
__randomizedtesting.SeedInfo.seed([8133F5B315A4BBBA:967CA69BB58D642]:0)
at 
org.apache.lucene.store.MockDirectoryWrapper.createOutput(MockDirectoryWrapper.java:654)
at 
org.apache.lucene.index.TestAllFilesCheckIndexHeader.checkOneFile(TestAllFilesCheckIndexHeader.java:106)
at 
org.apache.lucene.index.TestAllFilesCheckIndexHeader.checkIndexHeader(TestAllFilesCheckIndexHeader.java:81)
at 
org.apache.lucene.index.TestAllFilesCheckIndexHeader.test(TestAllFilesCheckIndexHeader.java:74)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)




Build Log:
[...truncated 467 lines...]
   [junit4] Suite: org.apache.lucene.index.TestAllFilesCheckIndexHeader
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestAllFilesCheckIndexHeader -Dtests.method=test 
-Dtests.seed=8133F5B315A4BBBA -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=vai-Latn 

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9310:
--



> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Fix For: trunk, 6.3
>
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, 
> SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9319) DELETEREPLICA should be able to accept just count and remove replicas intelligenty

[Nitin Sharma (JIRA)]

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

Nitin Sharma commented on SOLR-9319:


Ok i will rebase on master again. BTW i think you uploaded the patch for 9310 
here. 

> DELETEREPLICA should be able to accept  just count and remove replicas 
> intelligenty
> ---
>
> Key: SOLR-9319
> URL: https://issues.apache.org/jira/browse/SOLR-9319
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: DeleteReplicaPatch.jpg, Delete_Replica_count_1.jpg, 
> Delete_Replica_invalid.jpg, Delete_Replica_with_only_1replica.jpg, 
> Delete_replica_count2.jpg, Delte_replica_after.jpg, Delte_replica_before.jpg, 
> Old_deletereplica_api_works.jpg, SOLR-9310.patch, SOLR-9319.patch, 
> SOLR-9319.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-9310:


minor: since there is a cache now, we could sync on that and get rid of 
fingerprintLock

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Fix For: trunk, 6.3
>
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, 
> SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_102) - Build # 405 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/405/
Java: 32bit/jdk1.8.0_102 -server -XX:+UseSerialGC

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

Error Message:
Captured an uncaught exception in thread: Thread[id=18255, 
name=org.apache.solr.cloud.PeerSyncReplicationTest, state=RUNNABLE, 
group=TGRP-PeerSyncReplicationTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=18255, 
name=org.apache.solr.cloud.PeerSyncReplicationTest, state=RUNNABLE, 
group=TGRP-PeerSyncReplicationTest]
Caused by: java.lang.RuntimeException: 
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:51693/collection1]
at __randomizedtesting.SeedInfo.seed([4CE514C88D0AA4C8]:0)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.lambda$indexInBackground$0(PeerSyncReplicationTest.java:185)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:51693/collection1]
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:774)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.indexDoc(PeerSyncReplicationTest.java:347)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.lambda$indexInBackground$0(PeerSyncReplicationTest.java:180)
... 1 more
Caused by: org.apache.solr.client.solrj.SolrServerException: No live 
SolrServers available to handle this 
request:[http://127.0.0.1:51693/collection1]
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:382)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:768)
... 8 more
Caused by: org.apache.solr.client.solrj.SolrServerException: Server refused 
connection at: http://127.0.0.1:51693/collection1
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:599)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:403)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:355)
... 9 more
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
at 
java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:85)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at 
org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:117)
at 
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:497)
... 13 more


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

Error Message:
ObjectTracker found 3 object(s) that 

[jira] [Updated] (SOLR-9319) DELETEREPLICA should be able to accept just count and remove replicas intelligenty

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9319:
-
Attachment: SOLR-9310.patch

further optimized cache

> DELETEREPLICA should be able to accept  just count and remove replicas 
> intelligenty
> ---
>
> Key: SOLR-9319
> URL: https://issues.apache.org/jira/browse/SOLR-9319
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: DeleteReplicaPatch.jpg, Delete_Replica_count_1.jpg, 
> Delete_Replica_invalid.jpg, Delete_Replica_with_only_1replica.jpg, 
> Delete_replica_count2.jpg, Delte_replica_after.jpg, Delte_replica_before.jpg, 
> Old_deletereplica_api_works.jpg, SOLR-9310.patch, SOLR-9319.patch, 
> SOLR-9319.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_102) - Build # 6069 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6069/
Java: 64bit/jdk1.8.0_102 -XX:-UseCompressedOops -XX:+UseG1GC

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MockDirectoryWrapper, MDCAwareThreadPoolExecutor, MockDirectoryWrapper, 
MockDirectoryWrapper, TransactionLog]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 5 object(s) that were not 
released!!! [MockDirectoryWrapper, MDCAwareThreadPoolExecutor, 
MockDirectoryWrapper, MockDirectoryWrapper, TransactionLog]
at __randomizedtesting.SeedInfo.seed([DAD5B4DBB2D62717]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257)
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:367)
at java.lang.Thread.run(Thread.java:745)


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

Error Message:
java.lang.NullPointerException

Stack Trace:
com.google.common.util.concurrent.UncheckedExecutionException: 
java.lang.NullPointerException
at __randomizedtesting.SeedInfo.seed([DAD5B4DBB2D62717]:0)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2263)
at com.google.common.cache.LocalCache.get(LocalCache.java:4000)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4004)
at 
com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4874)
at org.apache.hadoop.security.Groups.getGroups(Groups.java:182)
at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation.getUsersFirstGroup(TestSolrCloudWithSecureImpersonation.java:64)
at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation.getImpersonatorSettings(TestSolrCloudWithSecureImpersonation.java:86)
at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation.startup(TestSolrCloudWithSecureImpersonation.java:99)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 

[jira] [Assigned] (SOLR-9406) SolrSuggester should selectively register close hook

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-9406:


Assignee: Joel Bernstein

> SolrSuggester should selectively register close hook
> 
>
> Key: SOLR-9406
> URL: https://issues.apache.org/jira/browse/SOLR-9406
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 4.10.3
>Reporter: Gethin James
>Assignee: Joel Bernstein
> Attachments: SOLR-9406.patch
>
>
> Currently this is the code for registering a close hook for SolrSuggester:
> {code}
> lookup = factory.create(config, core);
> core.addCloseHook(new CloseHook() {
>   @Override
>   public void preClose(SolrCore core) {
> if (lookup != null && lookup instanceof Closeable) {
>   try {
> ((Closeable) lookup).close();
>   } catch (IOException e) {
> LOG.warn("Could not close the suggester lookup.", e);
>   }
> }
>   }
>   
>   @Override
>   public void postClose(SolrCore core) {}
> });
> {code}
> Notice that the close hook is always registered, even though the close logic 
> runs conditionally.
> This can be changed so that the close hook is registered conditionally.
> This will help avoid memory leaks in scenarios where a custom component 
> reloads the SolrSuggester multiple times for the same core. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9406) SolrSuggester should selectively register close hook

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-9406:
-
Description: 
Currently this is the code for registering a close hook for SolrSuggester:

{code}
lookup = factory.create(config, core);
core.addCloseHook(new CloseHook() {
  @Override
  public void preClose(SolrCore core) {
if (lookup != null && lookup instanceof Closeable) {
  try {
((Closeable) lookup).close();
  } catch (IOException e) {
LOG.warn("Could not close the suggester lookup.", e);
  }
}
  }
  
  @Override
  public void postClose(SolrCore core) {}
});
{code}

Notice that the close hook is always registered, even though the close logic 
runs conditionally.

This can be changed so that the close hook is registered conditionally.

This will help avoid memory leaks in scenarios where a custom component reloads 
the SolrSuggester multiple times for the same core. 

  was:
Currently this is the code for registering a close hook for the solr suggester:

{code}
lookup = factory.create(config, core);
core.addCloseHook(new CloseHook() {
  @Override
  public void preClose(SolrCore core) {
if (lookup != null && lookup instanceof Closeable) {
  try {
((Closeable) lookup).close();
  } catch (IOException e) {
LOG.warn("Could not close the suggester lookup.", e);
  }
}
  }
  
  @Override
  public void postClose(SolrCore core) {}
});
{code}

Notice that the close hook is always registered, even though the close logic 
runs conditionally.

This can be changed so that the close hook is registered conditionally.

This will help avoid memory leaks in scenarios where a custom component reloads 
the SolrSuggester multiple times for the same core. 


> SolrSuggester should selectively register close hook
> 
>
> Key: SOLR-9406
> URL: https://issues.apache.org/jira/browse/SOLR-9406
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 4.10.3
>Reporter: Gethin James
> Attachments: SOLR-9406.patch
>
>
> Currently this is the code for registering a close hook for SolrSuggester:
> {code}
> lookup = factory.create(config, core);
> core.addCloseHook(new CloseHook() {
>   @Override
>   public void preClose(SolrCore core) {
> if (lookup != null && lookup instanceof Closeable) {
>   try {
> ((Closeable) lookup).close();
>   } catch (IOException e) {
> LOG.warn("Could not close the suggester lookup.", e);
>   }
> }
>   }
>   
>   @Override
>   public void postClose(SolrCore core) {}
> });
> {code}
> Notice that the close hook is always registered, even though the close logic 
> runs conditionally.
> This can be changed so that the close hook is registered conditionally.
> This will help avoid memory leaks in scenarios where a custom component 
> reloads the SolrSuggester multiple times for the same core. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9406) SolrSuggester should selectively register close hook

[Joel Bernstein (JIRA)]

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

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

Simple patch to conditionally register the close hook. The conditional logic is 
the same, it's just moved outside of the close hook itself, to control the 
close hook registration.

> SolrSuggester should selectively register close hook
> 
>
> Key: SOLR-9406
> URL: https://issues.apache.org/jira/browse/SOLR-9406
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 4.10.3
>Reporter: Gethin James
> Attachments: SOLR-9406.patch
>
>
> Currently this is the code for registering a close hook for the solr 
> suggester:
> {code}
> lookup = factory.create(config, core);
> core.addCloseHook(new CloseHook() {
>   @Override
>   public void preClose(SolrCore core) {
> if (lookup != null && lookup instanceof Closeable) {
>   try {
> ((Closeable) lookup).close();
>   } catch (IOException e) {
> LOG.warn("Could not close the suggester lookup.", e);
>   }
> }
>   }
>   
>   @Override
>   public void postClose(SolrCore core) {}
> });
> {code}
> Notice that the close hook is always registered, even though the close logic 
> runs conditionally.
> This can be changed so that the close hook is registered conditionally.
> This will help avoid memory leaks in scenarios where a custom component 
> reloads the SolrSuggester multiple times for the same core. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Noble Paul (JIRA)]

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

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

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Fix For: trunk, 6.3
>
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, 
> SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [POLL] What should happen to PyLucene now?

[Andi Vajda]

On Sun, 10 Jul 2016, Andi Vajda wrote:


Thank you Jan for starting this thread !

Of the nine people that responded, three were interested in a new 6.x 
release, with two offering to help make a new release happen.


A couple of others showed interest in JCC only.

Here is what I can propose:
 1. I can make sure a PyLucene can be buildt from Lucene 6.x and runs.


PyLucene can now be built from Lucene's branch 6.x, on Mac OS X.
It builds, loads, can run a couple of simple tests like test_Binary.py and
test_BinaryDocument.py.

Here is how one can reproduce what I just did:
  - cd ~/apache
  - git clone --branch branch_6x https://github.com/apache/lucene-solr.git 
lucene.6x
  - cd 
  - svn update
make sure you have a modern setuptools (if you are on linux, the
setuptools patching done by JCC to be able to build a plain shared
library most likely needs to be refreshed or maybe even eliminated).
  - _install/bin/pip uninstall setuptools
  - _install/bin/pip install setuptools
  - cd jcc
  - ../_install/bin/python setup.py build install
  - cd ..
  - make sources (this copies the lucene tree from the github tree cloned)
  - make compile install

If all worked, you can then:
  - _install/bin/python
  >>> import lucene
  >>> lucene.initVM()
  - _install/bin/python test/test_Binary.py

I have a Python virtual env installed in pylucene/_install, this helps with 
keeping different versions of software separate.



 2. Volunteers should then help in porting old 4.x tests, if they still
apply, and import new tests from the current Lucene suite as they see
fit.


All other tests need to be carefully ported to match all the numerous API 
changes and disappeared classes. For similar reasons, the extensions jar 
does not build and is not currently included in the build. Its source java 
classes need to be refreshed as tests get refreshed to 6.x.


Andi..


 3. Once everyone involved is happy with test coverage (which was never
exhaustive and need not be), a new release can be rolled and the
Lucene PMC put to contribution again for votes.

If any of these steps end up stalling, no new release happens and the 
PyLucene subproject gets shutdown, eventually.


As for JCC, regardless of what happens to PyLucene itself, I'd very much like 
to port it to Python 3. I've already done this once, the port is available in 
a branch [1]. It 'just' needs to be refreshed. I intend to eventually get to 
this, unless someone with a stronger itch beats me to it.


Andi..

[1] http://svn.apache.org/repos/asf/lucene/pylucene/branches/python_3/jcc/


On Sat, 2 Jul 2016, Aric Coady wrote:


[X]  I?ll help make a new release happen, if I get some help!

On Jul 1, 2016, at 9:35 AM, Alexander Yaworsky 
 wrote:


Well, this bothered me (not a dev but fixed some of your bugs locally
long long ago, why didn't send patches is another story). Here's my
opinion, as a user. 1. Be in sync with lucene is a must. 2. Be in sync
with python is a must. Therefore,


And +1 on staying current with lucene and python.


Question: What should happen to PyLucene now?

[ ]  I?m happy with the last 4.x release, no need for new releases
[ ]  Please, a new 6.x release (but I can?t contribute)
[ ]  I?ll help make a new release happen, if I get some help!
[X]  Only care about the JCC part
[X]  Close down the sub project -- IF YOU ARE UNABLE TO MAINTAIN
[ ]  Don?t care. I?m no longer a user
[X]  Other: Move JCC to P3


Actually, the brilliant part of this project is JCC. In a company I
work for we still use it to utilize Java libraries from python. This
is the fastest solution and this sub-project must exist separately
imo. We do not use Lucene since 00's btw.

Thanks.

Alexander.

[jira] [Updated] (SOLR-9406) SolrSuggester should selectively register close hook

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-9406:
-
Description: 
Currently this is the code for registering a close hook for the solr suggester:

{code}
lookup = factory.create(config, core);
core.addCloseHook(new CloseHook() {
  @Override
  public void preClose(SolrCore core) {
if (lookup != null && lookup instanceof Closeable) {
  try {
((Closeable) lookup).close();
  } catch (IOException e) {
LOG.warn("Could not close the suggester lookup.", e);
  }
}
  }
  
  @Override
  public void postClose(SolrCore core) {}
});
{code}

Notice that the close hook is always registered, even though the close logic 
runs conditionally.

This can be changed so that the close hook is registered conditionally.

This will help avoid memory leaks in scenarios where a custom component reloads 
the SolrSuggester multiple times for the same core. 

  was:
SolrSuggester init method register a CloseHook keeping a reference to 
LookupFactory.

If init() is called multiple times then multiple close hooks are added.  These 
are kept in memory and not reclaimed.

See https://issues.alfresco.com/jira/browse/ACE-5148


> SolrSuggester should selectively register close hook
> 
>
> Key: SOLR-9406
> URL: https://issues.apache.org/jira/browse/SOLR-9406
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 4.10.3
>Reporter: Gethin James
>
> Currently this is the code for registering a close hook for the solr 
> suggester:
> {code}
> lookup = factory.create(config, core);
> core.addCloseHook(new CloseHook() {
>   @Override
>   public void preClose(SolrCore core) {
> if (lookup != null && lookup instanceof Closeable) {
>   try {
> ((Closeable) lookup).close();
>   } catch (IOException e) {
> LOG.warn("Could not close the suggester lookup.", e);
>   }
> }
>   }
>   
>   @Override
>   public void postClose(SolrCore core) {}
> });
> {code}
> Notice that the close hook is always registered, even though the close logic 
> runs conditionally.
> This can be changed so that the close hook is registered conditionally.
> This will help avoid memory leaks in scenarios where a custom component 
> reloads the SolrSuggester multiple times for the same core. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9310:
--

Addressing the thread safety issue and compare absolute values of versions in 
UpdateLog

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Fix For: trunk, 6.3
>
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, 
> SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [jira] [Commented] (SOLR-9424) Deleting is not happening in solr 5.4.1 with Manifold CF For Sharepoint

[Erick Erickson]

You have mis-matched begin/end tags.
bla

Note that  is paired with 

Actually that should be rejected,but if it's begin interpreted as a
query, it's really deleting everything _except_ any doc with
id "1543097641453223936" note no minus sign which
translates as "NOT".

So try with properly matched end tags of , enclose the
id (including the minus sign) in quotes etc.

Best,
Erick

On Sun, Aug 21, 2016 at 11:17 PM, soundarya g (JIRA)  wrote:
>
> [ 
> https://issues.apache.org/jira/browse/SOLR-9424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15430107#comment-15430107
>  ]
>
> soundarya g commented on SOLR-9424:
> ---
>
> if i tried deleting the command like below means ,it s deleting all the doc 
> from index,
>
> .../update?commit=true=-1543097641453223936
>
>> Deleting is not happening in solr 5.4.1 with Manifold CF For Sharepoint
>> ---
>>
>> Key: SOLR-9424
>> URL: https://issues.apache.org/jira/browse/SOLR-9424
>> Project: Solr
>>  Issue Type: Bug
>>  Security Level: Public(Default Security Level. Issues are Public)
>>Reporter: soundarya g
>>
>> Im trying to crawl the Sharepoint List using manifold CF with Solr 5.4.1.whn 
>> the particular item got deleted manifold cf is able to send query to 
>> solr,but solr is not updating the deleted documents in index.
>> Following are Solr logs:
>> 2016-08-19 13:16:28.361 INFO  (qtp1450821318-15) [   x:tika] 
>> o.a.s.u.p.LogUpdateProcessorFactory [tika] webapp=/solr path=/update 
>> params={wt=xml=2.2} 
>> {delete=[http://az0165d:2525/sites/ASLC/Lists/DemoList/30_.000 
>> (-1543097641453223936)]} 0 11
>> 2016-08-19 13:16:28.391 INFO  (commitScheduler-15-thread-1) [   x:tika] 
>> o.a.s.u.DirectUpdateHandler2 start 
>> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
>> 2016-08-19 13:16:28.422 INFO  (commitScheduler-15-thread-1) [   x:tika] 
>> o.a.s.c.SolrDeletionPolicy SolrDeletionPolicy.onCommit: commits: num=2
>>   
>> commit{dir=NRTCachingDirectory(MMapDirectory@E:\solenewtry\solr-5.4.1\solr-5.4.1\server\solr\tika\data\index
>>  lockFactory=org.apache.lucene.store.NativeFSLockFactory@38f651f7; 
>> maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_c9,generation=441}
>>   
>> commit{dir=NRTCachingDirectory(MMapDirectory@E:\solenewtry\solr-5.4.1\solr-5.4.1\server\solr\tika\data\index
>>  lockFactory=org.apache.lucene.store.NativeFSLockFactory@38f651f7; 
>> maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_ca,generation=442}
>> 2016-08-19 13:16:28.422 INFO  (commitScheduler-15-thread-1) [   x:tika] 
>> o.a.s.c.SolrDeletionPolicy newest commit generation = 442
>> 2016-08-19 13:16:28.422 INFO  (commitScheduler-15-thread-1) [   x:tika] 
>> o.a.s.s.SolrIndexSearcher Opening Searcher@5021dfc7[tika] main
>> 2016-08-19 13:16:28.422 INFO  
>> (searcherExecutor-7-thread-1-processing-x:tika) [   x:tika] 
>> o.a.s.c.QuerySenderListener QuerySenderListener sending requests to 
>> Searcher@5021dfc7[tika] 
>> main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_ei(5.4.1):C1)))}
>> 2016-08-19 13:16:28.422 INFO  
>> (searcherExecutor-7-thread-1-processing-x:tika) [   x:tika] 
>> o.a.s.c.QuerySenderListener QuerySenderListener done.
>> 2016-08-19 13:16:28.422 INFO  
>> (searcherExecutor-7-thread-1-processing-x:tika) [   x:tika] o.a.s.c.SolrCore 
>> [tika] Registered new searcher Searcher@5021dfc7[tika] 
>> main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_ei(5.4.1):C1)))}
>> 2016-08-19 13:16:28.438 INFO  (commitScheduler-15-thread-1) [   x:tika] 
>> o.a.s.u.DirectUpdateHandler2 end_commit_flush
>> 2016-08-19 13:16:30.489 INFO  (qtp1450821318-16) [   x:tika] 
>> o.a.s.u.DirectUpdateHandler2 start 
>> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
>> 2016-08-19 13:16:30.489 INFO  (qtp1450821318-16) [   x:tika] 
>> o.a.s.u.DirectUpdateHandler2 No uncommitted changes. Skipping IW.commit.
>> 2016-08-19 13:16:30.489 INFO  (qtp1450821318-16) [   x:tika] 
>> o.a.s.c.SolrCore SolrIndexSearcher has not changed - not re-opening: 
>> org.apache.solr.search.SolrIndexSearcher
>> 2016-08-19 13:16:30.489 INFO  (qtp1450821318-16) [   x:tika] 
>> o.a.s.u.DirectUpdateHandler2 end_commit_flush
>> 2016-08-19 13:16:30.489 INFO  (qtp1450821318-16) [   x:tika] 
>> o.a.s.u.p.LogUpdateProcessorFactory [tika] webapp=/solr path=/update/extract 
>> params={commit=true=xml=2.2} {commit=} 0 3
>> 2016-08-19 13:17:28.801 INFO  (qtp1450821318-14) [   x:tika] 
>> o.a.s.c.S.Request [tika] webapp=/solr path=/select 
>> params={q=*:*=true=json&_=1471612648791} hits=1 status=0 QTime=0
>> --
>> i have committed 

[jira] [Updated] (SOLR-9406) SolrSuggester should selectively register close hook

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-9406:
-
Summary: SolrSuggester should selectively register close hook  (was: 
SolrSuggester memory leak)

> SolrSuggester should selectively register close hook
> 
>
> Key: SOLR-9406
> URL: https://issues.apache.org/jira/browse/SOLR-9406
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 4.10.3
>Reporter: Gethin James
>
> SolrSuggester init method register a CloseHook keeping a reference to 
> LookupFactory.
> If init() is called multiple times then multiple close hooks are added.  
> These are kept in memory and not reclaimed.
> See https://issues.alfresco.com/jira/browse/ACE-5148



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Yonik Seeley (JIRA)]

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

Yonik Seeley edited comment on SOLR-9310 at 8/22/16 3:01 PM:
-

bq. What is the need for the cache?

Multiple replicas syncing against each other (or all replicas syncing against a 
new leader...)  I *think* it's part of the protocol to elect a new leader 
(because when one leader goes down, we don't know which replicas may have 
received the last update(s) and which replicas did not...)  In such a scenario, 
there is no active indexing because no new leader yet.
Some people run with large numbers of replicas (10 or 20), and hence the 
difference could well be large.



was (Author: ysee...@gmail.com):
bq. What is the need for the cache?

Multiple replicas syncing against each other... I *think* it's part of the 
protocol to elect a new leader (because when one leader goes down, we don't 
know which replicas may have received the last update(s) and which replicas did 
not...)  In such a scenario, there is no active indexing because no new leader 
yet.
Some people run with large numbers of replicas (10 or 20), and hence the 
difference could well be large.


> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Fix For: trunk, 6.3
>
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [VOTE] Release Lucene/Solr 6.2.0 RC1

[Adrien Grand]

+1
SUCCESS! [4:06:37.981292]

Le lun. 22 août 2016 à 09:00, Noble Paul  a écrit :

> I'm not sure if there is going to be a respin. SOLR-9310 is a
> worthwhile addition
>
> On Mon, Aug 22, 2016 at 12:22 AM, Uwe Schindler  wrote:
> > Hi,
> >
> > Thanks for testing on Linux, Steve (we chatted on IRC). I committed the
> new policy file change to master, 6.x and also 6.2 (but no respin needed,
> as this only fixes Jenkins).
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> >> -Original Message-
> >> From: Uwe Schindler [mailto:u...@thetaphi.de]
> >> Sent: Sunday, August 21, 2016 6:45 PM
> >> To: dev@lucene.apache.org
> >> Subject: RE: [VOTE] Release Lucene/Solr 6.2.0 RC1
> >>
> >> Oh, I tried it out, this works:
> >>
> >>   permission java.io.FilePermission "${tests.linedocsfile}", "read";
> >>
> >> But you have to be sure that the path is resolving correctly (if its
> relative).
> >>
> >> I will do a few more tests and commit this to master and 6.x +
> reconfigure
> >> Jenkins Nightly to enable Security Manager again.
> >>
> >> Uwe
> >>
> >> -
> >> Uwe Schindler
> >> H.-H.-Meier-Allee 63, D-28213 Bremen
> >> http://www.thetaphi.de
> >> eMail: u...@thetaphi.de
> >>
> >> > -Original Message-
> >> > From: Uwe Schindler [mailto:u...@thetaphi.de]
> >> > Sent: Sunday, August 21, 2016 6:37 PM
> >> > To: dev@lucene.apache.org
> >> > Cc: 'Steve Rowe' 
> >> > Subject: RE: [VOTE] Release Lucene/Solr 6.2.0 RC1
> >> >
> >> > Hi Steve,
> >> >
> >> > I am planning to add support for another way to dynamically specify
> the
> >> > linedocsfile in the policy file, so it respects a linedocsfile
> outside the
> >> > checkout. Simply copypasting the ${tests.linedocsfile} property into
> the
> >> policy
> >> > file only works if the path is absolute, which is not guaranteed by
> the
> >> > sysprop...
> >> >
> >> > I will open an issue if I have an idea.
> >> >
> >> > Uwe
> >> >
> >> > -
> >> > Uwe Schindler
> >> > H.-H.-Meier-Allee 63, D-28213 Bremen
> >> > http://www.thetaphi.de
> >> > eMail: u...@thetaphi.de
> >> > > From: Steve Rowe [mailto:sar...@gmail.com]
> >> > > Sent: Sunday, August 21, 2016 6:15 PM
> >> > > To: dev@lucene.apache.org
> >> > > Subject: Re: [VOTE] Release Lucene/Solr 6.2.0 RC1
> >> > >
> >> > > +1
> >> > >
> >> > > Smoke tester is happy now that it’s friends with Ant 1.9: SUCCESS!
> >> > > [0:28:35.468036]
> >> > >
> >> > > and docs, javadocs and changes look good.
> >> > >
> >> > > FYI I had to remove the “tests.linedocsfile” sysprop from my
> >> > > ~/lucene.build.properties to mollify the security manager.
> >> > >
> >> > > --
> >> > > Steve
> >> > > www.lucidworks.com
> >> > >
> >> > > > On Aug 21, 2016, at 4:48 AM, Michael McCandless
> >> > >  wrote:
> >> > > >
> >> > > > Duh, sorry, I forgot to push this fix to the smoke tester (to
> also accept
> >> ant
> >> > > 1.9.x).  I'll go do that!
> >> > > >
> >> > > > Mike McCandless
> >> > > >
> >> > > > http://blog.mikemccandless.com
> >> > > >
> >> > > > On Sun, Aug 21, 2016 at 2:38 AM, Christian Moen 
> >> > wrote:
> >> > > > Hi,
> >> > > >
> >> > > > My smoke tester gives the same error as Steve's.
> >> > > >
> >> > > > Best,
> >> > > > Christian
> >> > > >
> >> > > > > On Aug 21, 2016, at 08:35, Steve Rowe  wrote:
> >> > > > >
> >> > > > > Hi Mike,
> >> > > > >
> >> > > > > The branch_6_2 smoke tester is irritated with your choice of
> Ant:
> >> > > > >
> >> > > > > RuntimeError: JAR file
> >> > >
> >> >
> >> "/tmp/smoke_lucene_6.2.0_764d0f19151dbff6f5fcd9fc4b2682cf934590c5_1/
> >> > > unpack/lucene-6.2.0/codecs/lucene-codecs-6.2.0.jar" is missing "Ant-
> >> > > Version: Apache Ant 1.8" inside its META-INF/MANIFEST.MF
> >> > > > >
> >> > > > > And that file has:
> >> > > > >
> >> > > > >   Ant-Version: Apache Ant 1.9.7
> >> > > > >
> >> > > > > I saw a commit notification about addressing one aspect of
> that, but I
> >> > > guess not the manifest aspect?
> >> > > > >
> >> > > > > --
> >> > > > > Steve
> >> > > > > www.lucidworks.com
> >> > > > >
> >> > > > >> On Aug 20, 2016, at 10:01 AM, Michael McCandless
> >> > >  wrote:
> >> > > > >>
> >> > > > >> Please vote for release candidate 1 for Lucene/Solr 6.2.0
> >> > > > >>
> >> > > > >> The artifacts can be downloaded from:
> >> > > > >>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.2.0-
> >> RC1-
> >> > > rev764d0f19151dbff6f5fcd9fc4b2682cf934590c5
> >> > > > >>
> >> > > > >> You can run the smoke tester directly with this command:
> >> > > > >>
> >> > > > >> python3 -u dev-tools/scripts/smokeTestRelease.py \
> >> > > > >>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.2.0-
> >> RC1-
> >> > > rev764d0f19151dbff6f5fcd9fc4b2682cf934590c5
> >> > > > >>
> >> > > > >> Here's my +1
> >> > > > >>
> >> > > > >> 

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-9310:


bq. What is the need for the cache?

Multiple replicas syncing against each other... I *think* it's part of the 
protocol to elect a new leader (because when one leader goes down, we don't 
know which replicas may have received the last update(s) and which replicas did 
not...)  In such a scenario, there is no active indexing because no new leader 
yet.
Some people run with large numbers of replicas (10 or 20), and hence the 
difference could well be large.


> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Fix For: trunk, 6.3
>
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

[Michael McCandless (JIRA)]

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

Michael McCandless commented on SOLR-6246:
--

Fixing {{AnalyzingInfixSuggester}} to close the writer at the end of build 
seems reasonable?

> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
> Attachments: SOLR-6246-test.patch, SOLR-6246-test.patch, 
> SOLR-6246.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Keith Laban (JIRA)]

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

Keith Laban commented on SOLR-9310:
---

What is the need for the cache? I seems like there would only ever be a cache 
hit if if there is no active indexing. It seems like the added complexity is 
not worth the potential small performance boost.  

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Fix For: trunk, 6.3
>
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Yonik Seeley (JIRA)]

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

Yonik Seeley edited comment on SOLR-9310 at 8/22/16 2:44 PM:
-

Reopening... the cache that was added in SolrIndexSearcher is not thread safe 
and is checked outside synchronization.

Also, about this comment:
{code}
// TODO what happens if updates came out of order, would cached fingerprint 
still be valid?
// May be caching fingerprint may lead more problems
{code}

The index fingerprint only depends on what documents are in the index, not on 
their order in the index.  And since the cache is on SolrIndexSearcher (which 
has a static view of the index), it will be impossible for fingerprint to 
change for a given max version.  The comment should probably just be removed to 
avoid confusion.

In changes on UpdateLog:
{code}
+  if(ptr.version > maxVersion) continue;
{code}

versions can be negative for deletes, so we should really be checking against 
the absolute value of ptr.version



was (Author: ysee...@gmail.com):
Reopening... the cache that was added in SolrIndexSearcher is not thread safe 
and is checked outside synchronization.

Also, about this comment:
{code}
// TODO what happens if updates came out of order, would cached fingerprint 
still be valid?
// May be caching fingerprint may lead more problems
{code}

The index fingerprint only depends on what documents are in the index, not on 
their order in the index.  And since the cache is on SolrIndexSearcher (which 
has a static view of the index), it will be impossible for fingerprint to 
change for a given max version.  The comment should probably just be removed to 
avoid confusion.

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Fix For: trunk, 6.3
>
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6913) Standard/Classic/UAX tokenizers could be more ram efficient

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6913:
-

I started looking into this but I think our find-replace hacks in our ant jflex 
task are incompatible with the code generated from jflex's master branch. I 
tried messing around with them but couldn't make tests pass, so I'm stuck on 
that first.

There is already an issue at jflex 
(https://github.com/jflex-de/jflex/issues/196), I added a comment with the idea 
I am looking at.

> Standard/Classic/UAX tokenizers could be more ram efficient
> ---
>
> Key: LUCENE-6913
> URL: https://issues.apache.org/jira/browse/LUCENE-6913
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-6913.not.a.patch
>
>
> These tokenizers map codepoints to character classes with the following 
> datastructure (loaded in clinit):
> {noformat}
>   private static char [] zzUnpackCMap(String packed) {
> char [] map = new char[0x11];
> {noformat}
> This requires 2MB RAM for each tokenizer class (in trunk 6MB if all 3 classes 
> are loaded, in branch_5x 10MB since there are 2 additional backwards compat 
> classes).
> On the other hand, none of our tokenizers actually use a huge number of 
> character classes, so {{char}} is overkill: e.g. this map can safely be a 
> byte [] and we can save half the memory. Perhaps it could make these 
> tokenizers faster too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Proposal to Move Solr Ref Guide off Confluence

[David Smiley]

On Mon, Aug 22, 2016 at 9:46 AM Jan Høydahl  wrote:

> Pull requests for docs is a great plus so more people can contribute. The
> online version-specific docs can then have a link below each page
> encouraging people to contribute through PR to version-branch or by comment
> system.
>
> An issue with only maintaining the next-release branch is that docs on
> master will get out of date. But that is perhaps not a problem since there
> will not be an online HTML version of master? Anyway, with a merge-forward
> strategy, we could e.g. merge to master after each point release on 6.x, to
> avoid the gap becoming too large over time.
>

Yup; +1!  I think that's how we should do it.

-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Reopened] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Yonik Seeley (JIRA)]

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

Yonik Seeley reopened SOLR-9310:


Reopening... the cache that was added in SolrIndexSearcher is not thread safe 
and is checked outside synchronization.

Also, about this comment:
{code}
// TODO what happens if updates came out of order, would cached fingerprint 
still be valid?
// May be caching fingerprint may lead more problems
{code}

The index fingerprint only depends on what documents are in the index, not on 
their order in the index.  And since the cache is on SolrIndexSearcher (which 
has a static view of the index), it will be impossible for fingerprint to 
change for a given max version.  The comment should probably just be removed to 
avoid confusion.

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Fix For: trunk, 6.3
>
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Noble Paul (JIRA)]

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

Noble Paul resolved SOLR-9310.
--
   Resolution: Fixed
Fix Version/s: 6.3
   trunk

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Fix For: trunk, 6.3
>
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9319) DELETEREPLICA should be able to accept just count and remove replicas intelligenty

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9319:
--

I refactored everything out from {{OverseerCollectionMessageHandler}} I don't 
think this applies to the trunk after that

> DELETEREPLICA should be able to accept  just count and remove replicas 
> intelligenty
> ---
>
> Key: SOLR-9319
> URL: https://issues.apache.org/jira/browse/SOLR-9319
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: DeleteReplicaPatch.jpg, Delete_Replica_count_1.jpg, 
> Delete_Replica_invalid.jpg, Delete_Replica_with_only_1replica.jpg, 
> Delete_replica_count2.jpg, Delte_replica_after.jpg, Delte_replica_before.jpg, 
> Old_deletereplica_api_works.jpg, SOLR-9319.patch, SOLR-9319.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8029) Modernize and standardize Solr APIs

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8029:
--

Thanks [~steve_rowe] 

I shall post a detailed response after I go through all of them

> Modernize and standardize Solr APIs
> ---
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: API, EaseOfUse
> Fix For: 6.0
>
> Attachments: SOLR-8029.patch, SOLR-8029.patch, SOLR-8029.patch, 
> SOLR-8029.patch
>
>
> Solr APIs have organically evolved and they are sometimes inconsistent with 
> each other or not in sync with the widely followed conventions of HTTP 
> protocol. Trying to make incremental changes to make them modern is like 
> applying band-aid. So, we have done a complete rethink of what the APIs 
> should be. The most notable aspects of the API are as follows:
> The new set of APIs will be placed under a new path {{/solr2}}. The legacy 
> APIs will continue to work under the {{/solr}} path as they used to and they 
> will be eventually deprecated.
> There are 4 types of requests in the new API 
> * {{/v2//*}} : Hit a collection directly or manage 
> collections/shards/replicas 
> * {{/v2//*}} : Hit a core directly or manage cores 
> * {{/v2/cluster/*}} : Operations on cluster not pertaining to any collection 
> or core. e.g: security, overseer ops etc
> This will be released as part of a major release. Check the link given below 
> for the full specification.  Your comments are welcome
> [Solr API version 2 Specification | http://bit.ly/1JYsBMQ]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Proposal to Move Solr Ref Guide off Confluence

[Jan Høydahl]

Pull requests for docs is a great plus so more people can contribute. The 
online version-specific docs can then have a link below each page encouraging 
people to contribute through PR to version-branch or by comment system.

An issue with only maintaining the next-release branch is that docs on master 
will get out of date. But that is perhaps not a problem since there will not be 
an online HTML version of master? Anyway, with a merge-forward strategy, we 
could e.g. merge to master after each point release on 6.x, to avoid the gap 
becoming too large over time.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 19. aug. 2016 kl. 19.48 skrev Tomás Fernández Löbbe :
> 
> Thanks for taking time for looking at these options Casandra. I specially 
> agree with the third of the painful points you mentioned, the fact that we 
> can't maintain online documentation for different versions. I like that we 
> have a released PDF version for every minor version, but 99.9% of the time 
> I'm online and I just want to go to the online version and browse the HTML 
> docs, it's a pain that I can't just choose my version there. 
> I also agree 100% with Doug's point, that we should make sure that links to 
> the current documentation pages are correctly forwarded to the new docs.
> Accepting pull requests would also be nice, many of the comments in 
> Confluence are "there is a typo in…" or "X section is missing parameter Y", I 
> bet many of those comments will become PRs if we offered the option (don't 
> know if this can be handled without Jira)
> 
> About branching and merging, we currently write docs for the next version 
> (minor usually), very few things are written for master only, and they 
> currently live in a separate Confluence area that's not released. One option 
> would be keep doing this, which will prevent many merges (at the cost of 
> making it more difficult to release docs for new major versions).
> 
> in general, +1 for the idea.
> 
> Tomás
> 
> On Fri, Aug 19, 2016 at 10:23 AM, Chris Hostetter  > wrote:
> 
> : I am not against having multiple documentation branches -- I am *for*
> : that.  I am against emulating our current source code practice of needing
> : to commit twice (two branches) for most things.  I think that should be the
> : exception, not the rule.  Only during a new dot-zero release would we be
> : compelled to merge forward the changes from the previous branch.
> 
> To be very clear, my point was that by moving out of confluence and to an
> asciidoc based system kept in git, we know have the *choice* to
> maintain/backport documentation for multiple versions, and an easy way to
> backport changes.
> 
> This is not even a viable *option* for us to consider with confluence.
> 
> if/how/when to backport/forward-port documentation is a policy question we
> can decide at a later date -- the hypothetical example i gave was just one
> that assumed we'd want to keep docs in sync with code --  The main take
> away was to point out that we can now make that decision for ourselves if
> we migrat out of confluence.
> 
> 
> 
> -Hoss
> http://www.lucidworks.com/ 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> 

[jira] [Commented] (SOLR-9215) QT parameter doesn't appear to function anymore

[JIRA]

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

Jan Høydahl commented on SOLR-9215:
---

+1 to this simplification, unless there is a very good reason why params should 
normally not be modifiable?

> QT parameter doesn't appear to function anymore
> ---
>
> Key: SOLR-9215
> URL: https://issues.apache.org/jira/browse/SOLR-9215
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0, master (7.0)
>Reporter: Markus Jelsma
> Fix For: 6.2, master (7.0)
>
>
> The qt parameter doesn't seem to work anymore. A call directly to the /terms 
> handler returns actual terms, as expected. Using the select handler but with 
> qt=terms returns noting.
> http://localhost:8983/solr/logs/select?qt=terms=true=compound_digest=100=index
> {code}
> 
> 
> 
>   0
>   0
>   
> terms
> true
> compound_digest
> 100
> index
>   
> 
> 
> 
> 
> {code}
> A peculiar detail, my unit tests that rely on the qt parameter are not 
> affected.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-6246:
-

bq. close the writer after build. In analyzing the method usages

I think that might be a good solution.

Solr does not support real time updates to the suggester so its fine from it's 
perspective.

>From a Lucene API standpoint it's probably not ideal but maybe not all that 
>bad?

This is what I am thinking -

Create a Lucene issue in which {{AnalyzingInfixSuggester#build}} closes the 
writer by default at the end.

The {{add}} and {{update}} methods call {{ensureOpen}}  and those who do 
frequent real time updates directly via lucene won't see any slowdowns.

 [~mikemccand] - Would this approach have any major drawback from Lucene's 
perspective?  Else I can go ahead an tackle this in a Lucene issue

> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
> Attachments: SOLR-6246-test.patch, SOLR-6246-test.patch, 
> SOLR-6246.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7418) remove legacy numerics from join/ and queryparser/

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7418:
---

Thanks Robert!

> remove legacy numerics from join/ and queryparser/
> --
>
> Key: LUCENE-7418
> URL: https://issues.apache.org/jira/browse/LUCENE-7418
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: master (7.0)
>
> Attachments: LUCENE-7418.patch
>
>
> We have three modules with (temporary) dependency on backwards codecs:
> * join/
> * queryparser/
> * spatial-extras/
> this patch handles the first two, as they are easy. spatial-extras is more 
> complex as its legacy support is not clearly separated, so i'm not trying to 
> address that here.
> For join/ we just remove deprecations. For queryparser/, same thing, except 
> since solr exposes the xml queryparser, i moved the LegacyRangeQueryBuilder 
> to solr and hooked it into its subclass of the parser.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_102) - Build # 1547 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1547/
Java: 64bit/jdk1.8.0_102 -XX:+UseCompressedOops -XX:+UseG1GC

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

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:39878/forceleader_test_collection_shard1_replica3]

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: No live 
SolrServers available to handle this 
request:[http://127.0.0.1:39878/forceleader_test_collection_shard1_replica3]
at 
__randomizedtesting.SeedInfo.seed([456917B2CC299F37:A3FE2372F5AB6656]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:760)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.ForceLeaderTest.sendDoc(ForceLeaderTest.java:424)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:131)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Resolved] (SOLR-9412) Update Macro Expander for replacement logic

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-9412.
---
   Resolution: Fixed
Fix Version/s: 6.x
   master (7.0)

Thanks Jon!

> Update Macro Expander for replacement logic
> ---
>
> Key: SOLR-9412
> URL: https://issues.apache.org/jira/browse/SOLR-9412
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jon Dorando
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (7.0), 6.x
>
> Attachments: SOLR-9412.patch
>
>
> MacroExpander class was updated to allow to return null when replacement 
> parameters are missing. Right now it defaults to a blank space and it isn't 
> easily verifiable that a parameter was missing. Additionally, unit tests were 
> added for this case and the original use cases of Macro Expander.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7362) TestReqParamsAPI failing in jenkins

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-7362: Fix TestReqParamsAPI test failures


> TestReqParamsAPI failing in jenkins
> ---
>
> Key: SOLR-7362
> URL: https://issues.apache.org/jira/browse/SOLR-7362
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-7362.patch
>
>
> {noformat}
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4645/
> Java: 32bit/jdk1.8.0_40 -server -XX:+UseSerialGC
> 1 tests failed.
> FAILED:  org.apache.solr.handler.TestReqParamsAPI.test
> Error Message:
> Could not get expected value  'null' for path 'response/params/y/p' full 
> output: {   "responseHeader":{ "status":0, "QTime":1},   "response":{ 
> "znodeVersion":3, "params":{   "x":{ "a":"A val", 
> "b":"B val", "":{"v":0}},   "y":{ "p":"P val", 
> "q":"Q val", "":{"v":0}
> Stack Trace:
> java.lang.AssertionError: Could not get expected value  'null' for path 
> 'response/params/y/p' full output: {
>   "responseHeader":{
> "status":0,
> "QTime":1},
>   "response":{
> "znodeVersion":3,
> "params":{
>   "x":{
> "a":"A val",
> "b":"B val",
> "":{"v":0}},
>   "y":{
> "p":"P val",
> "q":"Q val",
> "":{"v":0}
> at 
> __randomizedtesting.SeedInfo.seed([D0DB18ECE165C505:588F27364F99A8FD]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at 
> org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:405)
> at 
> org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:236)
> at 
> org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:71)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9412) Update Macro Expander for replacement logic

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9412: Add failOnMissingParams option to MacroExpander, add 
TestMacroExpander class. (Jon Dorando, Christine Poerschke)


> Update Macro Expander for replacement logic
> ---
>
> Key: SOLR-9412
> URL: https://issues.apache.org/jira/browse/SOLR-9412
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jon Dorando
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9412.patch
>
>
> MacroExpander class was updated to allow to return null when replacement 
> parameters are missing. Right now it defaults to a blank space and it isn't 
> easily verifiable that a parameter was missing. Additionally, unit tests were 
> added for this case and the original use cases of Macro Expander.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (LUCENE-7418) remove legacy numerics from join/ and queryparser/

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-7418.
-
   Resolution: Fixed
Fix Version/s: master (7.0)

> remove legacy numerics from join/ and queryparser/
> --
>
> Key: LUCENE-7418
> URL: https://issues.apache.org/jira/browse/LUCENE-7418
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: master (7.0)
>
> Attachments: LUCENE-7418.patch
>
>
> We have three modules with (temporary) dependency on backwards codecs:
> * join/
> * queryparser/
> * spatial-extras/
> this patch handles the first two, as they are easy. spatial-extras is more 
> complex as its legacy support is not clearly separated, so i'm not trying to 
> address that here.
> For join/ we just remove deprecations. For queryparser/, same thing, except 
> since solr exposes the xml queryparser, i moved the LegacyRangeQueryBuilder 
> to solr and hooked it into its subclass of the parser.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7418) remove legacy numerics from join/ and queryparser/

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7418: remove deprecated legacy numerics from join/ and queryparser/


> remove legacy numerics from join/ and queryparser/
> --
>
> Key: LUCENE-7418
> URL: https://issues.apache.org/jira/browse/LUCENE-7418
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7418.patch
>
>
> We have three modules with (temporary) dependency on backwards codecs:
> * join/
> * queryparser/
> * spatial-extras/
> this patch handles the first two, as they are easy. spatial-extras is more 
> complex as its legacy support is not clearly separated, so i'm not trying to 
> address that here.
> For join/ we just remove deprecations. For queryparser/, same thing, except 
> since solr exposes the xml queryparser, i moved the LegacyRangeQueryBuilder 
> to solr and hooked it into its subclass of the parser.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestDownShardTolerantSearch.searchingShouldFailWithoutTolerantSearchSetToTrue

Error Message:
Error message from server should have the name of the down shard

Stack Trace:
java.lang.AssertionError: Error message from server should have the name of the 
down shard
at 
__randomizedtesting.SeedInfo.seed([62D1C1B1ACD9A61B:500160BAA97BC77A]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.TestDownShardTolerantSearch.searchingShouldFailWithoutTolerantSearchSetToTrue(TestDownShardTolerantSearch.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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)
  

[jira] [Resolved] (SOLR-9354) ClusteringComponent added using Config API causes error when reloading the collection

[Dawid Weiss (JIRA)]

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

Dawid Weiss resolved SOLR-9354.
---
Resolution: Fixed

> ClusteringComponent added using Config API causes error when reloading the 
> collection
> -
>
> Key: SOLR-9354
> URL: https://issues.apache.org/jira/browse/SOLR-9354
> Project: Solr
>  Issue Type: Sub-task
>  Components: config-api, contrib - Clustering
>Affects Versions: 6.0.1
> Environment: SolrCloud on Windows with ZooKeeper 3.4.8
>Reporter: Alex D
>Assignee: Dawid Weiss
> Fix For: 6.1
>
>
> It is not possible to add a clustering search component when using the Config 
> API.
> Command I used to add the clustering component:
> curl -k -u admin:admin https://solrserver:8443/solr/customer/config -H 
> 'Content-type:application/json'  -d '{ "add-searchcomponent": 
> {"name":"clustering", "class": "solr.clustering.ClusteringComponent", 
> "engine": [{"name":"lingo","carrot.algorithm": 
> "org.carrot2.clustering.lingo.LingoClusteringAlgorithm"},  {"name":"stc", 
>"carrot.algorithm": "org.carrot2.clustering.stc.STCClusteringAlgorithm"}]} 
> }'
> Error I received from the curl command:
> ==
> {
>   "responseHeader":{
> "status":500,
> "QTime":30026},
>   "errorMessages":["1 out of 2 the property overlay to be of version 7 within 
> 30 seconds! Failed cores: 
> [https://solrserver:8443/solr/customer_shard1_replica1/]\n;],
>   "WARNING":"This response format is experimental.  It is likely to change in 
> the future.",
>   "error":{
> "metadata":[
>   "error-class","org.apache.solr.common.SolrException",
>   "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"1 out of 2 the property overlay to be of version 7 within 30 
> seconds! Failed cores: 
> [https://solrserver:8443/solr/customer_shard1_replica1/];,
> "trace":"org.apache.solr.common.SolrException: 1 out of 2 the property 
> overlay to be of version 7 within 30 seconds! Failed cores: 
> [https://solrserver:8443/solr/customer_shard1_replica1/]\r\n\tat 
> org.apache.solr.handler.SolrConfigHandler.waitForAllReplicasState(SolrConfigHandler.java:710)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler.access$600(SolrConfigHandler.java:91)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler$Command.handleCommands(SolrConfigHandler.java:426)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler$Command.handlePOST(SolrConfigHandler.java:266)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler$Command.access$100(SolrConfigHandler.java:143)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler.handleRequestBody(SolrConfigHandler.java:121)\r\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)\r\n\tat
>  org.apache.solr.core.SolrCore.execute(SolrCore.java:2053)\r\n\tat 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)\r\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)\r\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)\r\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)\r\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\r\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\r\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\r\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\r\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\r\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\r\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\r\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\r\n\tat
>  org.eclipse.jetty.server.Server.handle(Server.java:518)\r\n\tat 
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\r\n\tat 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)\r\n\tat
>  
> 

[jira] [Commented] (SOLR-9354) ClusteringComponent added using Config API causes error when reloading the collection

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on SOLR-9354:
---

This has been fixed and works for me in 6.1.0, although I can't quite pinpoint 
which issue the problem was connected to (scanned the changes log and code 
diff, but can't see it). It seems the core of the issue is in config overlay 
parsing, not the clustering component's code though.

> ClusteringComponent added using Config API causes error when reloading the 
> collection
> -
>
> Key: SOLR-9354
> URL: https://issues.apache.org/jira/browse/SOLR-9354
> Project: Solr
>  Issue Type: Sub-task
>  Components: config-api, contrib - Clustering
>Affects Versions: 6.0.1
> Environment: SolrCloud on Windows with ZooKeeper 3.4.8
>Reporter: Alex D
>Assignee: Dawid Weiss
> Fix For: 6.1
>
>
> It is not possible to add a clustering search component when using the Config 
> API.
> Command I used to add the clustering component:
> curl -k -u admin:admin https://solrserver:8443/solr/customer/config -H 
> 'Content-type:application/json'  -d '{ "add-searchcomponent": 
> {"name":"clustering", "class": "solr.clustering.ClusteringComponent", 
> "engine": [{"name":"lingo","carrot.algorithm": 
> "org.carrot2.clustering.lingo.LingoClusteringAlgorithm"},  {"name":"stc", 
>"carrot.algorithm": "org.carrot2.clustering.stc.STCClusteringAlgorithm"}]} 
> }'
> Error I received from the curl command:
> ==
> {
>   "responseHeader":{
> "status":500,
> "QTime":30026},
>   "errorMessages":["1 out of 2 the property overlay to be of version 7 within 
> 30 seconds! Failed cores: 
> [https://solrserver:8443/solr/customer_shard1_replica1/]\n;],
>   "WARNING":"This response format is experimental.  It is likely to change in 
> the future.",
>   "error":{
> "metadata":[
>   "error-class","org.apache.solr.common.SolrException",
>   "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"1 out of 2 the property overlay to be of version 7 within 30 
> seconds! Failed cores: 
> [https://solrserver:8443/solr/customer_shard1_replica1/];,
> "trace":"org.apache.solr.common.SolrException: 1 out of 2 the property 
> overlay to be of version 7 within 30 seconds! Failed cores: 
> [https://solrserver:8443/solr/customer_shard1_replica1/]\r\n\tat 
> org.apache.solr.handler.SolrConfigHandler.waitForAllReplicasState(SolrConfigHandler.java:710)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler.access$600(SolrConfigHandler.java:91)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler$Command.handleCommands(SolrConfigHandler.java:426)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler$Command.handlePOST(SolrConfigHandler.java:266)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler$Command.access$100(SolrConfigHandler.java:143)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler.handleRequestBody(SolrConfigHandler.java:121)\r\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)\r\n\tat
>  org.apache.solr.core.SolrCore.execute(SolrCore.java:2053)\r\n\tat 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)\r\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)\r\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)\r\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)\r\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\r\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\r\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\r\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\r\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\r\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\r\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\r\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\r\n\tat
>  

[jira] [Updated] (SOLR-9354) ClusteringComponent added using Config API causes error when reloading the collection

[Dawid Weiss (JIRA)]

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

Dawid Weiss updated SOLR-9354:
--
Fix Version/s: 6.1

> ClusteringComponent added using Config API causes error when reloading the 
> collection
> -
>
> Key: SOLR-9354
> URL: https://issues.apache.org/jira/browse/SOLR-9354
> Project: Solr
>  Issue Type: Sub-task
>  Components: config-api, contrib - Clustering
>Affects Versions: 6.0.1
> Environment: SolrCloud on Windows with ZooKeeper 3.4.8
>Reporter: Alex D
>Assignee: Dawid Weiss
> Fix For: 6.1
>
>
> It is not possible to add a clustering search component when using the Config 
> API.
> Command I used to add the clustering component:
> curl -k -u admin:admin https://solrserver:8443/solr/customer/config -H 
> 'Content-type:application/json'  -d '{ "add-searchcomponent": 
> {"name":"clustering", "class": "solr.clustering.ClusteringComponent", 
> "engine": [{"name":"lingo","carrot.algorithm": 
> "org.carrot2.clustering.lingo.LingoClusteringAlgorithm"},  {"name":"stc", 
>"carrot.algorithm": "org.carrot2.clustering.stc.STCClusteringAlgorithm"}]} 
> }'
> Error I received from the curl command:
> ==
> {
>   "responseHeader":{
> "status":500,
> "QTime":30026},
>   "errorMessages":["1 out of 2 the property overlay to be of version 7 within 
> 30 seconds! Failed cores: 
> [https://solrserver:8443/solr/customer_shard1_replica1/]\n;],
>   "WARNING":"This response format is experimental.  It is likely to change in 
> the future.",
>   "error":{
> "metadata":[
>   "error-class","org.apache.solr.common.SolrException",
>   "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"1 out of 2 the property overlay to be of version 7 within 30 
> seconds! Failed cores: 
> [https://solrserver:8443/solr/customer_shard1_replica1/];,
> "trace":"org.apache.solr.common.SolrException: 1 out of 2 the property 
> overlay to be of version 7 within 30 seconds! Failed cores: 
> [https://solrserver:8443/solr/customer_shard1_replica1/]\r\n\tat 
> org.apache.solr.handler.SolrConfigHandler.waitForAllReplicasState(SolrConfigHandler.java:710)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler.access$600(SolrConfigHandler.java:91)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler$Command.handleCommands(SolrConfigHandler.java:426)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler$Command.handlePOST(SolrConfigHandler.java:266)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler$Command.access$100(SolrConfigHandler.java:143)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler.handleRequestBody(SolrConfigHandler.java:121)\r\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)\r\n\tat
>  org.apache.solr.core.SolrCore.execute(SolrCore.java:2053)\r\n\tat 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)\r\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)\r\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)\r\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)\r\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\r\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\r\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\r\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\r\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\r\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\r\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\r\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\r\n\tat
>  org.eclipse.jetty.server.Server.handle(Server.java:518)\r\n\tat 
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\r\n\tat 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)\r\n\tat
>  
> 

[jira] [Commented] (SOLR-9412) Update Macro Expander for replacement logic

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9412: Add failOnMissingParams option to MacroExpander, add 
TestMacroExpander class. (Jon Dorando, Christine Poerschke)


> Update Macro Expander for replacement logic
> ---
>
> Key: SOLR-9412
> URL: https://issues.apache.org/jira/browse/SOLR-9412
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jon Dorando
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9412.patch
>
>
> MacroExpander class was updated to allow to return null when replacement 
> parameters are missing. Right now it defaults to a blank space and it isn't 
> easily verifiable that a parameter was missing. Additionally, unit tests were 
> added for this case and the original use cases of Macro Expander.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[Apache Jenkins Server]

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

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

Error Message:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:34170/yt/ra/forceleader_test_collection_shard1_replica1]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:34170/yt/ra/forceleader_test_collection_shard1_replica1]
at 
__randomizedtesting.SeedInfo.seed([C159867E2C183475:27CEB2BE159ACD14]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:774)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.ForceLeaderTest.sendDoc(ForceLeaderTest.java:424)
at 
org.apache.solr.cloud.ForceLeaderTest.assertSendDocFails(ForceLeaderTest.java:315)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:110)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_102) - Build # 17640 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17640/
Java: 32bit/jdk1.8.0_102 -server -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 23654 lines...]
-validate-source-patterns:
[source-patterns] package declaration precedes license header: 
solr/core/src/test/org/apache/solr/cloud/PeerSyncReplicationTest.java

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:763: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:130: Found 1 
violations in source files (package declaration precedes license header).

Total time: 62 minutes 27 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
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

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

[Policeman Jenkins Server]

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

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

Error Message:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:51042/md/ie/c8n_1x3_lf_shard1_replica1]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:51042/md/ie/c8n_1x3_lf_shard1_replica1]
at 
__randomizedtesting.SeedInfo.seed([103A85A9EAE90689:986EBA7344156B71]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:774)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1172)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1061)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:997)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:178)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:57)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9310: PeerSync fails on a node restart due to IndexFingerPrint mismatch


> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[ASF subversion and git services (JIRA)]

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

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

Commit 2f73129edae7541d5cf45c2085d9ca40ff048b9b in lucene-solr's branch 
refs/heads/branch_6x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2f73129 ]

SOLR-9310: PeerSync fails on a node restart due to IndexFingerPrint mismatch


> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[ASF subversion and git services (JIRA)]

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

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

Commit 80f916780798162a5c68875fed10ef1ff132c8f7 in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=80f9167 ]

SOLR-9310: PeerSync fails on a node restart due to IndexFingerPrint mismatch, 
precommit errors fixed


> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7411) Regex Query with Backreferences

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-7411:
-

Hi Martin. I'm sure there'd be more interest in your question/ issue if you 
included some more information about the advantage of using these MOAs over 
regular (regular) expressions. A link to the paper that you're writing should 
be good start once it's published! :) The sample test case is indeed very 
simple so I don't see how different MOAs are from regular automata (is it a 
theoretical difference in the languages they accept; is it a practical 
difference in runtime behavior -- much like with NFA/DFA traversal)?

> Regex Query with Backreferences
> ---
>
> Key: LUCENE-7411
> URL: https://issues.apache.org/jira/browse/LUCENE-7411
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/search
>Reporter: Martin Braun
>Priority: Minor
>
> Hi there,
> I am currently working on a Regex Engine that supports Backreferences while 
> not losing determinism. It uses Memory Occurence Automata (MOAs) in the 
> engine which are more powerful than normal DFA/NFAs. The engine does no 
> backtracking and recognizes Regexes that cannot be evaluated 
> deterministically as malformed. It has become more and more mature in the 
> last few weeks and I also implemented a Lucene Query that uses these Patterns 
> in the background. Now my question is: Is there any interest for this work to 
> be merged (or adapted) into Lucene core?
> https://github.com/s4ke/moar
> Usage example for the Lucene Query:
> https://github.com/s4ke/moar/blob/master/lucene/src/test/java/com/github/s4ke/moar/lucene/query/test/MoarQueryTest.java#L126
> Cheers,
> Martin



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-9354) ClusteringComponent added using Config API causes error when reloading the collection

[Dawid Weiss (JIRA)]

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

Dawid Weiss reassigned SOLR-9354:
-

Assignee: Dawid Weiss

> ClusteringComponent added using Config API causes error when reloading the 
> collection
> -
>
> Key: SOLR-9354
> URL: https://issues.apache.org/jira/browse/SOLR-9354
> Project: Solr
>  Issue Type: Sub-task
>  Components: config-api, contrib - Clustering
>Affects Versions: 6.0.1
> Environment: SolrCloud on Windows with ZooKeeper 3.4.8
>Reporter: Alex D
>Assignee: Dawid Weiss
>
> It is not possible to add a clustering search component when using the Config 
> API.
> Command I used to add the clustering component:
> curl -k -u admin:admin https://solrserver:8443/solr/customer/config -H 
> 'Content-type:application/json'  -d '{ "add-searchcomponent": 
> {"name":"clustering", "class": "solr.clustering.ClusteringComponent", 
> "engine": [{"name":"lingo","carrot.algorithm": 
> "org.carrot2.clustering.lingo.LingoClusteringAlgorithm"},  {"name":"stc", 
>"carrot.algorithm": "org.carrot2.clustering.stc.STCClusteringAlgorithm"}]} 
> }'
> Error I received from the curl command:
> ==
> {
>   "responseHeader":{
> "status":500,
> "QTime":30026},
>   "errorMessages":["1 out of 2 the property overlay to be of version 7 within 
> 30 seconds! Failed cores: 
> [https://solrserver:8443/solr/customer_shard1_replica1/]\n;],
>   "WARNING":"This response format is experimental.  It is likely to change in 
> the future.",
>   "error":{
> "metadata":[
>   "error-class","org.apache.solr.common.SolrException",
>   "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"1 out of 2 the property overlay to be of version 7 within 30 
> seconds! Failed cores: 
> [https://solrserver:8443/solr/customer_shard1_replica1/];,
> "trace":"org.apache.solr.common.SolrException: 1 out of 2 the property 
> overlay to be of version 7 within 30 seconds! Failed cores: 
> [https://solrserver:8443/solr/customer_shard1_replica1/]\r\n\tat 
> org.apache.solr.handler.SolrConfigHandler.waitForAllReplicasState(SolrConfigHandler.java:710)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler.access$600(SolrConfigHandler.java:91)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler$Command.handleCommands(SolrConfigHandler.java:426)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler$Command.handlePOST(SolrConfigHandler.java:266)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler$Command.access$100(SolrConfigHandler.java:143)\r\n\tat
>  
> org.apache.solr.handler.SolrConfigHandler.handleRequestBody(SolrConfigHandler.java:121)\r\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)\r\n\tat
>  org.apache.solr.core.SolrCore.execute(SolrCore.java:2053)\r\n\tat 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)\r\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)\r\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)\r\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)\r\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\r\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\r\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\r\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\r\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\r\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\r\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\r\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\r\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\r\n\tat
>  org.eclipse.jetty.server.Server.handle(Server.java:518)\r\n\tat 
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\r\n\tat 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)\r\n\tat
>  
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)\r\n\tat

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9310: PeerSync fails on a node restart due to IndexFingerPrint mismatch


> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [VOTE] Release Lucene/Solr 6.2.0 RC1

[Noble Paul]

I'm not sure if there is going to be a respin. SOLR-9310 is a
worthwhile addition

On Mon, Aug 22, 2016 at 12:22 AM, Uwe Schindler  wrote:
> Hi,
>
> Thanks for testing on Linux, Steve (we chatted on IRC). I committed the new 
> policy file change to master, 6.x and also 6.2 (but no respin needed, as this 
> only fixes Jenkins).
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>> -Original Message-
>> From: Uwe Schindler [mailto:u...@thetaphi.de]
>> Sent: Sunday, August 21, 2016 6:45 PM
>> To: dev@lucene.apache.org
>> Subject: RE: [VOTE] Release Lucene/Solr 6.2.0 RC1
>>
>> Oh, I tried it out, this works:
>>
>>   permission java.io.FilePermission "${tests.linedocsfile}", "read";
>>
>> But you have to be sure that the path is resolving correctly (if its 
>> relative).
>>
>> I will do a few more tests and commit this to master and 6.x + reconfigure
>> Jenkins Nightly to enable Security Manager again.
>>
>> Uwe
>>
>> -
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>> > -Original Message-
>> > From: Uwe Schindler [mailto:u...@thetaphi.de]
>> > Sent: Sunday, August 21, 2016 6:37 PM
>> > To: dev@lucene.apache.org
>> > Cc: 'Steve Rowe' 
>> > Subject: RE: [VOTE] Release Lucene/Solr 6.2.0 RC1
>> >
>> > Hi Steve,
>> >
>> > I am planning to add support for another way to dynamically specify the
>> > linedocsfile in the policy file, so it respects a linedocsfile outside the
>> > checkout. Simply copypasting the ${tests.linedocsfile} property into the
>> policy
>> > file only works if the path is absolute, which is not guaranteed by the
>> > sysprop...
>> >
>> > I will open an issue if I have an idea.
>> >
>> > Uwe
>> >
>> > -
>> > Uwe Schindler
>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>> > http://www.thetaphi.de
>> > eMail: u...@thetaphi.de
>> > > From: Steve Rowe [mailto:sar...@gmail.com]
>> > > Sent: Sunday, August 21, 2016 6:15 PM
>> > > To: dev@lucene.apache.org
>> > > Subject: Re: [VOTE] Release Lucene/Solr 6.2.0 RC1
>> > >
>> > > +1
>> > >
>> > > Smoke tester is happy now that it’s friends with Ant 1.9: SUCCESS!
>> > > [0:28:35.468036]
>> > >
>> > > and docs, javadocs and changes look good.
>> > >
>> > > FYI I had to remove the “tests.linedocsfile” sysprop from my
>> > > ~/lucene.build.properties to mollify the security manager.
>> > >
>> > > --
>> > > Steve
>> > > www.lucidworks.com
>> > >
>> > > > On Aug 21, 2016, at 4:48 AM, Michael McCandless
>> > >  wrote:
>> > > >
>> > > > Duh, sorry, I forgot to push this fix to the smoke tester (to also 
>> > > > accept
>> ant
>> > > 1.9.x).  I'll go do that!
>> > > >
>> > > > Mike McCandless
>> > > >
>> > > > http://blog.mikemccandless.com
>> > > >
>> > > > On Sun, Aug 21, 2016 at 2:38 AM, Christian Moen 
>> > wrote:
>> > > > Hi,
>> > > >
>> > > > My smoke tester gives the same error as Steve's.
>> > > >
>> > > > Best,
>> > > > Christian
>> > > >
>> > > > > On Aug 21, 2016, at 08:35, Steve Rowe  wrote:
>> > > > >
>> > > > > Hi Mike,
>> > > > >
>> > > > > The branch_6_2 smoke tester is irritated with your choice of Ant:
>> > > > >
>> > > > > RuntimeError: JAR file
>> > >
>> >
>> "/tmp/smoke_lucene_6.2.0_764d0f19151dbff6f5fcd9fc4b2682cf934590c5_1/
>> > > unpack/lucene-6.2.0/codecs/lucene-codecs-6.2.0.jar" is missing "Ant-
>> > > Version: Apache Ant 1.8" inside its META-INF/MANIFEST.MF
>> > > > >
>> > > > > And that file has:
>> > > > >
>> > > > >   Ant-Version: Apache Ant 1.9.7
>> > > > >
>> > > > > I saw a commit notification about addressing one aspect of that, but 
>> > > > > I
>> > > guess not the manifest aspect?
>> > > > >
>> > > > > --
>> > > > > Steve
>> > > > > www.lucidworks.com
>> > > > >
>> > > > >> On Aug 20, 2016, at 10:01 AM, Michael McCandless
>> > >  wrote:
>> > > > >>
>> > > > >> Please vote for release candidate 1 for Lucene/Solr 6.2.0
>> > > > >>
>> > > > >> The artifacts can be downloaded from:
>> > > > >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.2.0-
>> RC1-
>> > > rev764d0f19151dbff6f5fcd9fc4b2682cf934590c5
>> > > > >>
>> > > > >> You can run the smoke tester directly with this command:
>> > > > >>
>> > > > >> python3 -u dev-tools/scripts/smokeTestRelease.py \
>> > > > >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.2.0-
>> RC1-
>> > > rev764d0f19151dbff6f5fcd9fc4b2682cf934590c5
>> > > > >>
>> > > > >> Here's my +1
>> > > > >>
>> > > > >> SUCCESS! [0:21:39.759298]
>> > > > >>
>> > > > >> Mike McCandless
>> > > > >>
>> > > > >> http://blog.mikemccandless.com
>> > > > >
>> > > > >
>> > > > > -
>> > > > > 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_102) - Build # 17639 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17639/
Java: 64bit/jdk1.8.0_102 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.common.cloud.TestCollectionStateWatchers.testCanWaitForNonexistantCollection

Error Message:
waitForState was not triggered by collection creation

Stack Trace:
java.lang.AssertionError: waitForState was not triggered by collection creation
at 
__randomizedtesting.SeedInfo.seed([B9F41BE39C06DCAD:12D48055F1581886]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.common.cloud.TestCollectionStateWatchers.testCanWaitForNonexistantCollection(TestCollectionStateWatchers.java:207)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 13264 lines...]
   [junit4] Suite: org.apache.solr.common.cloud.TestCollectionStateWatchers
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9310:
--

bq.It probably won't hurt to use `maxVersion` before returning versions

You are right. It won't hurt peersync because getUpdates take care of it. But , 
for correctness of the API the the following should be true 

{{fingerPrint.maxEncounteredVersion== max(versions)}}

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9424) Deleting is not happening in solr 5.4.1 with Manifold CF For Sharepoint

[soundarya g (JIRA)]

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

soundarya g commented on SOLR-9424:
---

if i tried deleting the command like below means ,it s deleting all the doc 
from index,

.../update?commit=true=-1543097641453223936

> Deleting is not happening in solr 5.4.1 with Manifold CF For Sharepoint
> ---
>
> Key: SOLR-9424
> URL: https://issues.apache.org/jira/browse/SOLR-9424
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: soundarya g
>
> Im trying to crawl the Sharepoint List using manifold CF with Solr 5.4.1.whn 
> the particular item got deleted manifold cf is able to send query to solr,but 
> solr is not updating the deleted documents in index.
> Following are Solr logs:
> 2016-08-19 13:16:28.361 INFO  (qtp1450821318-15) [   x:tika] 
> o.a.s.u.p.LogUpdateProcessorFactory [tika] webapp=/solr path=/update 
> params={wt=xml=2.2} 
> {delete=[http://az0165d:2525/sites/ASLC/Lists/DemoList/30_.000 
> (-1543097641453223936)]} 0 11
> 2016-08-19 13:16:28.391 INFO  (commitScheduler-15-thread-1) [   x:tika] 
> o.a.s.u.DirectUpdateHandler2 start 
> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> 2016-08-19 13:16:28.422 INFO  (commitScheduler-15-thread-1) [   x:tika] 
> o.a.s.c.SolrDeletionPolicy SolrDeletionPolicy.onCommit: commits: num=2
>   
> commit{dir=NRTCachingDirectory(MMapDirectory@E:\solenewtry\solr-5.4.1\solr-5.4.1\server\solr\tika\data\index
>  lockFactory=org.apache.lucene.store.NativeFSLockFactory@38f651f7; 
> maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_c9,generation=441}
>   
> commit{dir=NRTCachingDirectory(MMapDirectory@E:\solenewtry\solr-5.4.1\solr-5.4.1\server\solr\tika\data\index
>  lockFactory=org.apache.lucene.store.NativeFSLockFactory@38f651f7; 
> maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_ca,generation=442}
> 2016-08-19 13:16:28.422 INFO  (commitScheduler-15-thread-1) [   x:tika] 
> o.a.s.c.SolrDeletionPolicy newest commit generation = 442
> 2016-08-19 13:16:28.422 INFO  (commitScheduler-15-thread-1) [   x:tika] 
> o.a.s.s.SolrIndexSearcher Opening Searcher@5021dfc7[tika] main
> 2016-08-19 13:16:28.422 INFO  (searcherExecutor-7-thread-1-processing-x:tika) 
> [   x:tika] o.a.s.c.QuerySenderListener QuerySenderListener sending requests 
> to Searcher@5021dfc7[tika] 
> main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_ei(5.4.1):C1)))}
> 2016-08-19 13:16:28.422 INFO  (searcherExecutor-7-thread-1-processing-x:tika) 
> [   x:tika] o.a.s.c.QuerySenderListener QuerySenderListener done.
> 2016-08-19 13:16:28.422 INFO  (searcherExecutor-7-thread-1-processing-x:tika) 
> [   x:tika] o.a.s.c.SolrCore [tika] Registered new searcher 
> Searcher@5021dfc7[tika] 
> main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_ei(5.4.1):C1)))}
> 2016-08-19 13:16:28.438 INFO  (commitScheduler-15-thread-1) [   x:tika] 
> o.a.s.u.DirectUpdateHandler2 end_commit_flush
> 2016-08-19 13:16:30.489 INFO  (qtp1450821318-16) [   x:tika] 
> o.a.s.u.DirectUpdateHandler2 start 
> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> 2016-08-19 13:16:30.489 INFO  (qtp1450821318-16) [   x:tika] 
> o.a.s.u.DirectUpdateHandler2 No uncommitted changes. Skipping IW.commit.
> 2016-08-19 13:16:30.489 INFO  (qtp1450821318-16) [   x:tika] o.a.s.c.SolrCore 
> SolrIndexSearcher has not changed - not re-opening: 
> org.apache.solr.search.SolrIndexSearcher
> 2016-08-19 13:16:30.489 INFO  (qtp1450821318-16) [   x:tika] 
> o.a.s.u.DirectUpdateHandler2 end_commit_flush
> 2016-08-19 13:16:30.489 INFO  (qtp1450821318-16) [   x:tika] 
> o.a.s.u.p.LogUpdateProcessorFactory [tika] webapp=/solr path=/update/extract 
> params={commit=true=xml=2.2} {commit=} 0 3
> 2016-08-19 13:17:28.801 INFO  (qtp1450821318-14) [   x:tika] 
> o.a.s.c.S.Request [tika] webapp=/solr path=/select 
> params={q=*:*=true=json&_=1471612648791} hits=1 status=0 QTime=0 
> --
> i have committed manully in the browser by giving query like following:
> http://localhost:8981/solr/tika/update?commit=true
> but still deletion is not happening :(



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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