zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lei Zhang <lzvoya...@gmail.com>
Subject Re: Bizarre ZooKeeper Client Behaviour
Date Wed, 28 Apr 2010 04:51:32 GMT
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.


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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message