Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: zookeeper-user@hadoop.apache.org
Received-SPF: pass (nike.apache.org: domain of lzvoyager@gmail.com designates
 209.85.221.193 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=B6rrTcuS2x1Toj/CnCMpVvJQi48mO0T5XsXRVY5hZc3VCPbiNeQ0r3+TZesoeK44kF
         x6jEWuPNPA5cSd/JCYirH8Khw6wyB/fGxpEcR2ru7SVZq+FGUiTQX8YYbYS9DzVfkX2m
         jx5QtD3B8/EHvnns6AneGPnsFMlDInmGv0hNo=
MIME-Version: 1.0
In-Reply-To: <j2vc7d45fc71004271912re8117a7by8dd3a750dfc6164b@mail.gmail.com>
References: <y2nce892e5d1004271552p2f758573x422d47f78c60b2f9@mail.gmail.com>
	 <4BD77075.7070603@apache.org>
	 <p2z828d4a961004271717kec379b15mb589b8c60e937e41@mail.gmail.com>
	 <j2vc7d45fc71004271912re8117a7by8dd3a750dfc6164b@mail.gmail.com>
Date: Tue, 27 Apr 2010 21:51:32 -0700
Message-ID: <p2h828d4a961004272151h42a69c50we64caa0596e17707@mail.gmail.com>
Subject: Re: Bizarre ZooKeeper Client Behaviour
From: Lei Zhang <lzvoyager@gmail.com>
To: zookeeper-user@hadoop.apache.org
Content-Type: multipart/alternative; boundary=00c09f9c9c35909493048544c365

--00c09f9c9c35909493048544c365
Content-Type: text/plain; charset=ISO-8859-1

Ted -

You can think of this as a problem with using singleton in a multi-threaded
program. The solution that provides better code readability at affordable
cost should win.

Specifically the problem I am trying to solve is this:

We have a multi-threaded webapp based on a framework (means I am not yet
able to find out how the framework spawns threads, cleaning up the threads).
Each thread has local states that must be cleaned up on zookeeper fatal
error; and the desired zookeeper error recovery is to reopen the session.

The choices on the table are:
1. 1 zk session for the whole webapp
2. 1 zk session for each thread

Option 1 proves to be tricky to implement - since more than 1 threads can
catch zk fatal error, I would have to implement proper synchronization
mechanism to prevent same session being closed/reopened rapidly back to
back; besides, I need to implement a way to request the threads that did not
catch zk fatal error to clean up their local states.

Option 2 I haven't prototyped out completely. It is likely the webapp may
become laden with zk threads. I suspect we'll run into zk threads race
condition. I'd like to hear from people who actually struggled with similar
design decision.

Lei

On Tue, Apr 27, 2010 at 7:12 PM, Ted Dunning <ted.dunning@gmail.com> wrote:

> Lei,
>
> A contrary question for you is why you don't just share zk sessions within
> a
> single process.
>
>

--00c09f9c9c35909493048544c365--