hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-8220) ZKFailoverController doesn't handle failure to become active correctly
Date Fri, 30 Mar 2012 18:06:27 GMT

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

Aaron T. Myers commented on HADOOP-8220:

Patch looks pretty good to me, Todd. A few little comments. +1 once these are addressed:

# Any reason we shouldn't make SLEEP_AFTER_FAILURE_TO_BECOME_ACTIVE configurable?
# There's some inconsistency in capitalization between "reJoinElection" and "rejoinElectionAfterFailureToBecomeActive"
# Might want to do a s/System.currentTimeMillis/Util.now/g
# Any reason we shouldn't make LOG_INTERVAL_MS configurable?
# Add @VisibleForTesting to sleepFor, since it would be private (and probably static) otherwise.
Maybe even add a comment saying why it's not static.
# Considering the comment says "after sleeping for a short period" in TestActiveStandbyElector#testFailToBecomeActive,
maybe also verify that sleepFor was called? Likewise in testFailToBecomeActiveAfterZKDisconnect.
> ZKFailoverController doesn't handle failure to become active correctly
> ----------------------------------------------------------------------
>                 Key: HADOOP-8220
>                 URL: https://issues.apache.org/jira/browse/HADOOP-8220
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: auto-failover, ha
>    Affects Versions: 0.23.3, 0.24.0
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>            Priority: Critical
>         Attachments: hadoop-8220.txt, hadoop-8220.txt, hadoop-8220.txt, hadoop-8220.txt
> The ZKFC doesn't properly handle the case where the monitored service fails to become
active. Currently, it catches the exception and logs a warning, but then continues on, after
calling quitElection(). This causes a NPE when it later tries to use the same zkClient instance
while handling that same request. There is a test case, but the test case doesn't ensure that
the node that had the failure is later able to recover properly.

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