[jira] [Created] (SOLR-12258) V2 API should "retry" for unresolved collections/aliases (like V1 does)

["David Smiley (JIRA)" <ji...@apache.org>]

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