[ https://issues.apache.org/jira/browse/SOLR-5859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946663#comment-13946663 ]
Noble Paul edited comment on SOLR-5859 at 3/25/14 3:27 PM: ----------------------------------------------------------- new strategy, implement a new operation called _quit_ . on receiving the message Overseer would set isClosed=true and the loop would exit as soon as the current in-flight message is done . After exiting the loop , it checks if it is still the leader (most likely it is) , if yes , remove the leader node from ZK and remove itself from the forefront of the election queue This would force a re-election among other peers was (Author: noble.paul): new strategy, implement a new operation called _quit_ . on receiving the message Overseer would set isClosed=true and the loop would exit as soon as the current in-flight message is done . After exiting the loop , it checks if it is still the leader (most likely it is) , if yes , remove the leader node from ZK and remove itself from the forefront of the election queue > Harden the Overseer restart mechanism > ------------------------------------- > > Key: SOLR-5859 > URL: https://issues.apache.org/jira/browse/SOLR-5859 > Project: Solr > Issue Type: Improvement > Reporter: Noble Paul > Assignee: Noble Paul > > SOLR-5476 depends on Overseer restart.The current strategy is to remove the > zk node for leader election and wait for STATUS_UPDATE_DELAY +100 ms and > start the new overseer. > Though overseer ops are short running, it is not a 100% foolproof strategy > because if an operation takes longer than the wait period there can be race > condition. -- This message was sent by Atlassian JIRA (v6.2#6252) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org