[
https://issues.apache.org/jira/browse/SOLR-12291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465803#comment-16465803
]
Anshum Gupta commented on SOLR-12291:
-------------------------------------
I like the overall idea. There's a bunch to cleanup, which I'm sure you already
know :)
I'll take a look at it when you've cleaned up but for now, I'd suggest not
creating the asyncTracker perhaps if there's no async id? It might need some
extra plumbing but would be cleaner I feel. wdyt ?
Also, about the legacy cloud core creation, do you intend to commit this to 7x?
> OverseerCollectionMessageHandler sliceCmd assumes only one replica exists on
> each node
> --------------------------------------------------------------------------------------
>
> Key: SOLR-12291
> URL: https://issues.apache.org/jira/browse/SOLR-12291
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Backup/Restore, SolrCloud
> Reporter: Varun Thacker
> Priority: Major
> Attachments: SOLR-122911.patch
>
>
> The OverseerCollectionMessageHandler sliceCmd assumes only one replica exists
> on one node
> When multiple replicas of a slice are on the same node we only track one
> replica's async request. This happens because the async requestMap's key is
> "node_name"
> I discovered this when [~alabax] shared some logs of a restore issue, where
> the second replica got added before the first replica had completed it's
> restorecore action.
> While looking at the logs I noticed that the overseer never called
> REQUESTSTATUS for the restorecore action , almost as if it had missed
> tracking that particular async request.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
