lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shalin Shekhar Mangar (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-6956) DeleteReplicaTest fails sometimes.
Date Sun, 15 Feb 2015 13:47:11 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message