hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bikas Saha (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-8212) Improve ActiveStandbyElector's behavior when session expires
Date Thu, 29 Mar 2012 06:13:46 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241008#comment-13241008

Bikas Saha commented on HADOOP-8212:

I assume this delta will be committed to new branch?

Thats the behavior I found for ZK when I wrote the realZK test. I had an ill feeling about
simply nulling zkClient and checking for null in the original code. I had a doubt that the
old zkClient might still be alive and callback on its reference to the elector. Thats what
happened in the create case. Unfortunately I did not have a test with real ZK that actually
times out the session.

I think adding the check for stale zkClient actually makes the check session expired code
dead, as long as ZK client behaves this way. But it is a good to have in case ZK Client behavior
changes going forward.


> Improve ActiveStandbyElector's behavior when session expires
> ------------------------------------------------------------
>                 Key: HADOOP-8212
>                 URL: https://issues.apache.org/jira/browse/HADOOP-8212
>             Project: Hadoop Common
>          Issue Type: Improvement
>    Affects Versions: 0.23.3, 0.24.0
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>             Fix For: 2.0.0
>         Attachments: hadoop-8212-delta-bikas.txt, hadoop-8212.txt, hadoop-8212.txt
> Currently when the ZK session expires, it results in a fatal error being sent to the
application callback. This is not the best behavior -- for example, in the case of HA, if
ZK goes down, we would like the current state to be maintained, rather than causing either
NN to abort. When the ZK clients are able to reconnect, they should sort out the correct leader
based on the normal locking schemes.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message