[
https://issues.apache.org/jira/browse/SOLR-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13475136#comment-13475136
]
Mark Miller commented on SOLR-3939:
-----------------------------------
I think I see two issues so far:
1. SOLR-3940 - there can be a long wait that should not exist
2. We should consider a sync attempt from leader to replica that fails due to
404 a success. That is either a core that has been unloaded or a starting or
stopping Solr instance - treating it as a fail in the unloaded core (404) case
can cause our current leader choice strategy to fail to make progress. A
stopping or starting Solr instance will move on to recovery.
> Solr Cloud recovery and leader election when unloading leader core
> ------------------------------------------------------------------
>
> Key: SOLR-3939
> URL: https://issues.apache.org/jira/browse/SOLR-3939
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 4.0-BETA, 4.0
> Reporter: Joel Bernstein
> Assignee: Mark Miller
> Fix For: 4.0.1, 4.1, 5.0
>
>
> When a leader core is unloaded using the core admin api, the followers in the
> shard go into recovery but do not come out. Leader election doesn't take
> place and the shard goes down.
> This effects the ability to move a micro-shard from one Solr instance to
> another Solr instance.
> The problem does not occur 100% of the time but a large % of the time.
> To setup a test, startup Solr Cloud with a single shard. Add cores to that
> shard as replicas using core admin. Then unload the leader core using core
> admin.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
