lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <>
Subject [jira] [Assigned] (SOLR-10904) Unnecessary waiting during failover in case of failed core creation
Date Fri, 16 Jun 2017 16:02:00 GMT


Mark Miller reassigned SOLR-10904:

    Assignee: Mark Miller

> Unnecessary waiting during failover in case of failed core creation
> -------------------------------------------------------------------
>                 Key: SOLR-10904
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>    Affects Versions: master (7.0)
>            Reporter: Mihaly Toth
>            Assignee: Mark Miller
> Background failover thread checks for bad replicas. In case one is found it tries to
create it on another node. Then it waits for the new replica to show up in the cluster state.
It waits even if the core creation (initiated by itself) fails. 
> This situation does not occur on the happy path of the failover cases because the new
node was marked as alive. But in case the cluster is in an instable state, or user is restarting
the new node, or overseer is overloaded this extra wait will result in holding up this failover
> Proposed solution may be
> # wait for the result of the core creation
> # only if previous step is successful proceed to wait for cluster state change
> In code:
> {code}
> try {
>   Future<Boolean> future = updateExecutor.submit(() -> createSolrCore(collection,
createUrl, dataDir, ulogDir, coreNodeName, coreName, shardId));
>   future.get(30000L, TimeUnit.MILLISECONDS);
> } catch (InterruptedException | ExecutionException | TimeoutException e) {
>   log.error("Error creating core", e);
>   return false;
> } finally {
>   MDC.remove("OverseerAutoReplicaFailoverThread.createUrl");
> }
> {code}
> In such case we could consider moving core creation into the failover thread from the
> I can post a patch with these changes if the solution seems appropriate.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message