David Smiley created SOLR-12258:
-----------------------------------
Summary: V2 API should "retry" for unresolved collections/aliases
(like V1 does)
Key: SOLR-12258
URL: https://issues.apache.org/jira/browse/SOLR-12258
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrCloud, v2 API
Reporter: David Smiley
When using V1, if the request refers to a possible collection/alias that fails
to resolve, HttpSolrCall will invoke AliasesManager.update() then retry the
request as if anew (in collaboration with SolrDispatchFilter). If it fails to
resolve again we stop there and return an error; it doesn't go on forever.
V2 (V2HttpCall specifically) doesn't have this retry mechanism. It'll return
"no such collection or alias".
The retry will not only work for an alias but the retrying is a delay that will
at least help the odds of a newly made collection from being known to this Solr
node. It'd be nice if this was more explicit – i.e. if there was a mechanism
similar to AliasesManager.update() but for a collection. I'm not sure how to
do that?
BTW I discovered this while debugging a Jenkins failure of
TimeRoutedAliasUpdateProcessorTest.test where it early on simply goes to issue
a V2 based request to change the configuration of a collection that was created
immediately before it. It's pretty mysterious. I am aware of
SolrCloudTestCase.waitForState which is maybe something that needs to be
called? But if that were true then *every* SolrCloud test would need to use
it; it just seems wrong to me that we ought to use this method commonly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
