Return-Path: Delivered-To: apmail-hadoop-zookeeper-user-archive@locus.apache.org Received: (qmail 18496 invoked from network); 7 Jan 2009 17:15:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Jan 2009 17:15:16 -0000 Received: (qmail 778 invoked by uid 500); 7 Jan 2009 17:15:16 -0000 Delivered-To: apmail-hadoop-zookeeper-user-archive@hadoop.apache.org Received: (qmail 762 invoked by uid 500); 7 Jan 2009 17:15:16 -0000 Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: zookeeper-user@hadoop.apache.org Delivered-To: mailing list zookeeper-user@hadoop.apache.org Received: (qmail 751 invoked by uid 99); 7 Jan 2009 17:15:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Jan 2009 09:15:16 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=NO_RDNS_DOTCOM_HELO,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [216.145.54.173] (HELO mrout3.yahoo.com) (216.145.54.173) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Jan 2009 17:15:06 +0000 Received: from SP1-EX07CAS02.ds.corp.yahoo.com (sp1-ex07cas02.ds.corp.yahoo.com [216.252.116.138]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id n07HEDGj011226 for ; Wed, 7 Jan 2009 09:14:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version:return-path; b=NnRXOPyLM2URiJ3G09lnSMTDqfqcB2kDTGbV5XOCvb3z1Jluy9/kbn6kmFgmlvsG Received: from SP1-EX07CAS01.ds.corp.yahoo.com (216.252.116.137) by SP1-EX07CAS02.ds.corp.yahoo.com (216.252.116.138) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 7 Jan 2009 09:14:13 -0800 Received: from SP1-EX07VS02.ds.corp.yahoo.com ([216.252.116.136]) by sp1-ex07cas01.ds.corp.yahoo.com ([216.252.116.137]) with mapi; Wed, 7 Jan 2009 09:14:13 -0800 From: Benjamin Reed To: "zookeeper-user@hadoop.apache.org" Date: Wed, 7 Jan 2009 09:14:12 -0800 Subject: RE: Simpler ZooKeeper event interface.... Thread-Topic: Simpler ZooKeeper event interface.... Thread-Index: Aclw5Jslmy9hZr2bQkCZauZmynLxZQABeGti Message-ID: <6990D2A1CAF07E40A7CFE68A5FAAA15317F9B9B5BD@SP1-EX07VS02.ds.corp.yahoo.com> References: <30c6373b0901061657y61d329e4m73745c4f3a18ef8a@mail.gmail.com> <30c6373b0901062058x280d32a3j9883bf044829af35@mail.gmail.com> ,<4964D746.1090306@sun.com> In-Reply-To: <4964D746.1090306@sun.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org You don't demote yourself on disconnect. (Everyone else may still believe y= ou are the leader.) Check out the "Things to Remember about Watches" sectio= n in the programmer's guide. When you are disconnected from ZK you don't know what is happening, so you = have to act conservatively. Your session may or may not have expired. You w= ill not know for sure until you reconnect to ZK. ben ________________________________________ From: Thomas.Johnson@Sun.COM [Thomas.Johnson@Sun.COM] Sent: Wednesday, January 07, 2009 8:24 AM To: zookeeper-user@hadoop.apache.org Subject: Re: Simpler ZooKeeper event interface.... Hiram Chirino wrote: > Knowing about a disconnection may be important to some apps. For > example if an app uses ZK for leader election, and the leader gets > disconnected from ZK, he should give up being the leader, since a > different leader may get elected while he is disconnected from ZK. > > Is that necessarily true? My assumption is the following - if I'm connected to multiple ZK servers, then assuming the leader election recipe given in the docs, the leader needs to only demote itself if its session expires. Of course, doing the same on disconnect does not violate safety, it just seems too pessimistic. In the case of followers, a disconnected event would mean that they will have to wait for reconnection before being able to determine if one of them should in fact be the leader.