[
https://issues.apache.org/jira/browse/SOLR-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14321990#comment-14321990
]
Shalin Shekhar Mangar edited comment on SOLR-6956 at 2/15/15 1:46 PM:
----------------------------------------------------------------------
Looking through the logs of the latest failure of this test at
http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11802/
This test waits for all replicas of a new collection to be 'active' and then
calls delete replica API with onlyIfDown=true and expects it to fail. It does
this by matching the error message returned from the API call against the
following string:
bq. 'with onlyIfDown='true', but state is 'active'
However, in this particular run, the API call does fail but because the
OverseerCollectionProcessor finds the replica in 'recovering' state instead of
'active', the returned error message doesn't match. So the fix to the test is
easy. But what's more interesting is why the OverseerCollectionProcessor
couldn't see the latest cluster state when the client could. In the logs too, I
can see watchers being fired on the new cluster state before the call to delete
replica is made. I'll dig a bit more before I commit a fix to the test.
was (Author: shalinmangar):
Looking through the logs of the latest failure of this test at
http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11802/
This test waits for all replicas of a new collection to be 'active' and then
calls delete replica API with onlyIfDown=true and expects it to fail. It does
this by matching the error message returned from the API call against the
following string:
bq. 'with onlyIfDown='true', but state is 'active'
However, in this particular run, the API call does fail but because the
OverseerCollectionProcessor finds the replica in 'recovering' state instead of
'active' and therefore the returned error message doesn't match. So the fix to
the test is easy. But what's more interesting is why the
OverseerCollectionProcessor couldn't see the latest cluster state when the
client could. In the logs too, I can see watchers being fired on the new
cluster state before the call to delete replica is made. I'll dig a bit more
before I commit a fix to the test.
> DeleteReplicaTest fails sometimes.
> ----------------------------------
>
> Key: SOLR-6956
> URL: https://issues.apache.org/jira/browse/SOLR-6956
> Project: Solr
> Issue Type: Test
> Reporter: Mark Miller
> Priority: Minor
>
> I still see fails of this test sometimes:
> {noformat}
> java.lang.AssertionError: Should have had a good message here
> at
> __randomizedtesting.SeedInfo.seed([D765D9019AAF2D1E:56835719EDF04D22]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at
> org.apache.solr.cloud.DeleteReplicaTest.deleteLiveReplicaTest(DeleteReplicaTest.java:138)
> at
> org.apache.solr.cloud.DeleteReplicaTest.doTest(DeleteReplicaTest.java:89)
> {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
