Description
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.
Attachments
Attachments
Issue Links
- is related to
-
SOLR-12256 Aliases and eventual consistency (should use sync())
-
- Closed
-