curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julio Lopez (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-15) LeaderSelector may (undetectably) fail to elect
Date Thu, 18 Apr 2013 21:00:15 GMT

    [ https://issues.apache.org/jira/browse/CURATOR-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635685#comment-13635685
] 

Julio Lopez commented on CURATOR-15:
------------------------------------

We are running into a slight variation / narrower case of the issue reported here (filed CURATOR-16
for it), and thus the solutions may be slightly different.  The issues are that:

a. LeaderSelector fails under certain circumstances, and there's no way of either getting
a notification or querying the selector to know whether there was an unrecoverable failure.
 Perhaps this needs a notification mechanism.

b. LeaderSelector should re-attempt when auto-requeue is true (for certain types of failures).
 Perhaps this needs proper handling of those specific failures (and would take care of CURATOR-16).

                
> LeaderSelector may (undetectably) fail to elect
> -----------------------------------------------
>
>                 Key: CURATOR-15
>                 URL: https://issues.apache.org/jira/browse/CURATOR-15
>             Project: Apache Curator
>          Issue Type: Bug
>            Reporter: Shevek
>            Assignee: Jordan Zimmerman
>
> In LeaderSelector, if mutex.acquire() throws an Exception, for example because CuratorFramework.getZooKeeper()
threw a previously-enqueued background exception, then that failure will propagate out of
doWork and doWorkLoop, and kill the background submission onto the executor service.
> This means that a leaderselector which was start()ed will NEVER elect, and this situation
is NOT DETECTABLE externally, since that exception happens on a private executorservice thread
and is not client visible. It's impossible to look at a LeaderSelector and decide whether
it is still "viable".
> This can leave a machine/process "hung" and not automatically recoverable within curator.
> Either isQueued() needs to be exposed, which means that a leader is either elected or
queued; or the finally{} block which calls clearIsQueued() needs also to set state to CLOSED
or FAILED, so that we can query this failure externally.

--
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

Mime
View raw message