[
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.
+1
> 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
