[
https://issues.apache.org/jira/browse/SOLR-5859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13951784#comment-13951784
]
Noble Paul edited comment on SOLR-5859 at 3/29/14 7:04 AM:
-----------------------------------------------------------
I guess I have managed to eliminate the complexity from the leader
prioritization process
The problem was that the cancel election was not removing the watcher and just
deleting the corresponding node in ZK.
OCP should check soon after the messages are read because there is a huge time
wait for OCP reading messages
[~markrmil...@gmail.com] your review will be appreciated
was (Author: noble.paul):
I guess I have managed to eliminate the complexity from the leader election
process
The problem was that the cancel election was not removing the watcher and just
deleting the corresponding node in ZK.
OCP should check soon after the messages are read because there is a huge time
wait for OCP reading messages
[~markrmil...@gmail.com] your review will be appreciated
> 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
> Attachments: SOLR-5859.patch, SOLR-5859.patch
>
>
> 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
