[
https://issues.apache.org/jira/browse/SOLR-12258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16464033#comment-16464033
]
David Smiley commented on SOLR-12258:
-------------------------------------
The attached patch:
* V2HttpCall: moved the alias resolution into getDocCollection and renamed to
resolveDocCollection to handle both alias & collection resolution. Added retry
logic, both for aliases and for collections (via
ZkStateReader.forceUpdateCollection(collection)
* HttpSolrCall: after we call aliases.update(), added a call to
{{cores.getZkController().zkStateReader.forceUpdateCollection(collectionName);}}
And I removed the comment about admin UI elements triggering this code path
because this is no longer true – I checked by using Solr with a breakpoint both
cloud and standard, and by researching the original issue.
* ZkStateReader.forceUpdateCollection: added TODO comment that we ought to
call ZooKeeper.sync().
Tests are running now.
Any comments [~gus_heck], [~noble.paul] or [~shalinmangar]? If not I'll commit
this maybe Monday. I'm looking forward to not seeing spurious CI failures for
TimeRoutedAliasUpdateProcessorTest that will be solved by this.
> 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
> Priority: Major
> 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: [email protected]
For additional commands, e-mail: [email protected]
