You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "David Smiley (JIRA)" <ji...@apache.org> on 2018/05/08 19:14:00 UTC
[jira] [Resolved] (SOLR-12258) V2 API should "retry" for unresolved
collections/aliases (like V1 does)
[ https://issues.apache.org/jira/browse/SOLR-12258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Smiley resolved SOLR-12258.
---------------------------------
Resolution: Fixed
Assignee: David Smiley
Fix Version/s: 7.4
> 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
> Assignee: David Smiley
> Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12258.patch, SOLR-12258.patch
>
>
> 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