Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: zookeeper-user@hadoop.apache.org
Received-SPF: pass (athena.apache.org: domain of ted.dunning@gmail.com
 designates 209.85.216.204 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=I/Vmc1rI22CVMPlzb+5v11Iopxu4OgYnZP4lCrBhu72lMyhPOMSSJVQq6cKTE49qdo
         jexr1+/nESz8gY+EP3hRiqGcW64TeU6jo3D2tluKEHiy02lbUeq3x6v3a81dZ4RyGBXj
         ocHguKnXj01qoM7riFTrI2pxSIQUQh0AkFeQs=
MIME-Version: 1.0
In-Reply-To: <f60bfea61001251912u7c277fdl3081a65051053f2d@mail.gmail.com>
References: <34fd060d1001230058ybeca0b1n79bdcd97e63be76@mail.gmail.com>
	<C7824B4B.2D695%mahadev@yahoo-inc.com>
 <34fd060d1001242109k3f735a61y845b0a932bb43773@mail.gmail.com>
	<c7d45fc71001242208n292731b1s7555b0993dff3db1@mail.gmail.com>
	<f60bfea61001242305gfa35d10n30281b72374c52ec@mail.gmail.com>
	<c7d45fc71001242325r3bacb5a8rebfde018c2f36587@mail.gmail.com>
	<f60bfea61001250223g38959126rd7340f50e9afcf68@mail.gmail.com>
	<c7d45fc71001251353g52656617q940e6cf0635db252@mail.gmail.com>
	<f60bfea61001251912u7c277fdl3081a65051053f2d@mail.gmail.com>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Mon, 25 Jan 2010 20:02:24 -0800
Message-ID: <c7d45fc71001252002u6bf82f7ev950c1e73f7b7a1e7@mail.gmail.com>
Subject: Re: Using zookeeper to assign a bunch of long-running tasks to nodes
	(without unhandled tasks and double-handled tasks)
To: zookeeper-user@hadoop.apache.org
Content-Type: multipart/alternative; boundary=0016e649c184a3d96c047e095bdd

--0016e649c184a3d96c047e095bdd
Content-Type: text/plain; charset=UTF-8

On Mon, Jan 25, 2010 at 7:12 PM, Qing Yan <qingyan@gmail.com> wrote:

> ...
> 2) Lose connection with the (quorum of) ZK cluster, e.g. C3 as mentioned
> before. if the situation continues will lead to CONNECTION_EXPIRE.
> ...
> About case 2), seems to me there is indeed a need for application to know
> about this, per ZK documentation :
>
> When you disconnect from a server (for example, when the server fails), you
> will not get any watches until the connection is reestablished. For this
> reason session events are sent to all outstanding watch handlers. Use
> session events to go into a safe mode: you will not be receiving events
> while disconnected, so your process should act conservatively in that mode.
>
> http://hadoop.apache.org/zookeeper/docs/r3.2.2/zookeeperProgrammers.html
> But from reading your post, it seems that case 2) will no longer be
> reported
> to application, hence the confusion.
>

I don't know if CONNECTION_LOSS would or would not be reported.  As you
point out, it may well be important to report it or to report it after a
short period of loss without reconnection.

I think that my preference would be that transactions during a connection
loss block until the connection is restored or the session expires.  That is
probably a matter of taste.  Some people would probably prefer that most
operations return quickly even at the cost of considerably more complex
semantics on their part.  Sequential creation, in particular, should
probably always block if the session is still conceivably alive.

 In any case, I think the documentation needs to be updated to reflect the
> latest design/contract change.
>

Of course.

--0016e649c184a3d96c047e095bdd--