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.
Patrick
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.
>>
>>
>
|