[
https://issues.apache.org/jira/browse/SOLR-12258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16466632#comment-16466632
]
Gus Heck commented on SOLR-12258:
---------------------------------
I think it might read better to move the contents of the two
{code:java}
if (secondTry){code}
blocks into the
{code:java}
if(!secondTry){code}
block just before recursion. (conditionally "Update and recurse" rather than
recurse then conditionally update)
Also in inspecting usages of
{code:java}
forceUpdateCollection(collectionName) {code}
I came across the javadoc comment on
{code:java}
org.apache.solr.common.cloud.ZkStateReader#forciblyRefreshAllClusterStateSlow{code}
method. That method seems like an even bigger candidate for a Zookeeper.sync(),
but maybe that's another jira
> 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]
