zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Hunt <ph...@apache.org>
Subject Re: Bizarre ZooKeeper Client Behaviour
Date Wed, 28 Apr 2010 16:16:36 GMT
You might take a look at src/contrib/rest implementation which I created 
a while back. This uses a singleton ZK session for all requests. It's 
very simple approach and hasn't been proven in battle yet though (not 
many ppl I know of that have tried it). Most likely it's much simpler 
than what Lei is trying to build. Also, there is currently no 
authentication implemented in the rest proxy, this might be hard to add 
with the singleton approach (given a single session would share all 
credentials). Not sure if this would matter in Lei's case but it is 
something to think about if you have distinct "users" running in the 
same vm.


On 04/27/2010 09:51 PM, Lei Zhang wrote:
> 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.

View raw message