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
On 04/27/2010 09:51 PM, Lei Zhang wrote:
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
On Tue, Apr 27, 2010 at 7:12 PM, Ted Dunning<ted.dunn...@gmail.com> wrote:
A contrary question for you is why you don't just share zk sessions within