lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-8135) SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection reproducible failure
Date Thu, 04 Feb 2016 05:33:39 GMT

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

Erick Erickson commented on SOLR-8135:
--------------------------------------

Noble:

Well, perhaps I phrased things poorly, so let's start over and not even consider the test.

bq: A race condition should not put a core in an unrecoverable error situation

Totally agree. If I understand the patch though, the reload operation and the delete operation
are competing. In this particular case the reload was caused by changing the configs, but
that's largely immaterial. The delete got in there before the reload operation and closed
the core. What happens with throwing this new exception is that the reload operation still
fails in the sense that the core is still unavailable right? I don't quite see how throwing
a new exception and catching it but not adding it to the failures list changes the fact that
the core failed to reload; it's still unavailable. How does it ever recover?

Or are you saying that in this case, since the core is deleted it really doesn't _need_ to
recover? That still doesn't seem to cover the general case of the core being closed during
a reload operation. There's a comment somewhere in the code that perhaps the reload should
be retried. It'll still fail in this case, but are there others where reloading will succeed
and thus we should retry?

All that said, it'll be at least tomorrow night before I can beast this patch....





> SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection reproducible failure
> ----------------------------------------------------------------------------------
>
>                 Key: SOLR-8135
>                 URL: https://issues.apache.org/jira/browse/SOLR-8135
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: Trunk
>            Reporter: Hoss Man
>            Assignee: Noble Paul
>         Attachments: SOLR-8135.failure.log, SOLR-8135.patch, SOLR-8135.patch
>
>
> No idea what's going on here, noticed it while testing out an unrelated patch -- seed
reproduces against pristine trunk...
> {noformat}
>    [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=SolrCloudExampleTest -Dtests.method=testLoadDocsIntoGettingStartedCollection
-Dtests.seed=59EA523FFF6CB60F -Dtests.slow=true -Dtests.locale=es_MX -Dtests.timezone=Africa/Porto-Novo
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>    [junit4] FAILURE 49.5s | SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection
<<<
>    [junit4]    > Throwable #1: java.lang.AssertionError: Delete action failed!
>    [junit4]    > 	at __randomizedtesting.SeedInfo.seed([59EA523FFF6CB60F:4A896050CE030FA9]:0)
>    [junit4]    > 	at org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169)
>    [junit4]    > 	at org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145)
>    [junit4]    > 	at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
>    [junit4]    > 	at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
> {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