Return-Path: X-Original-To: apmail-incubator-mesos-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-mesos-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C907C10513 for ; Thu, 20 Jun 2013 19:14:20 +0000 (UTC) Received: (qmail 34008 invoked by uid 500); 20 Jun 2013 19:14:20 -0000 Delivered-To: apmail-incubator-mesos-dev-archive@incubator.apache.org Received: (qmail 33962 invoked by uid 500); 20 Jun 2013 19:14:20 -0000 Mailing-List: contact mesos-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: mesos-dev@incubator.apache.org Delivered-To: mailing list mesos-dev@incubator.apache.org Received: (qmail 33953 invoked by uid 99); 20 Jun 2013 19:14:20 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Jun 2013 19:14:20 +0000 Date: Thu, 20 Jun 2013 19:14:20 +0000 (UTC) From: "Benjamin Mahler (JIRA)" To: mesos-dev@incubator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (MESOS-422) Master leader election should be more robust to stale ephemeral nodes MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/MESOS-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler updated MESOS-422: ---------------------------------- Fix Version/s: (was: 0.12.0) 0.14.0 > Master leader election should be more robust to stale ephemeral nodes > --------------------------------------------------------------------- > > Key: MESOS-422 > URL: https://issues.apache.org/jira/browse/MESOS-422 > Project: Mesos > Issue Type: Bug > Components: master > Reporter: Bill Farner > Assignee: Benjamin Mahler > Priority: Minor > Fix For: 0.14.0 > > > When a leading master exits abruptly, it may fatefully restart and think it's the leader. If particularly unlucky, this could result in a set of masters that are indefinitely unstable. > Sequence of events: > - Master process becomes leader > - Master process exits, session expiration counter begins > - Master process restarts, reads leader node contents, and decides it's the leader (based on PID equality) > - Previous master session expires, node is deleted > - Master decides a different master is leader, commits suicide > - Rinse, repeat for newly-created master node > The salient fact here is that leaders should be concerned with "did i create the leader node" (ignoring node data) while clients want to be apprised of leader's node data. > Relevant code: > https://github.com/apache/mesos/blob/trunk/src/detector/detector.cpp#L548 > ZK leader election recipe, for reference: > http://zookeeper.apache.org/doc/trunk/recipes.html#sc_leaderElection -- 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