Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper, mail # user - How to deal with fork() properly when using the zkc mt lib


Copy link to this message
-
Re: How to deal with fork() properly when using the zkc mt lib
Michi Mutsuzaki 2012-05-10, 23:49
Ah right, the session will become invalid when you call
zookeeper_close on handle A. I don't know if there is a way to suspend
a session. I'll let someone more knowledgeable answer.

Thanks!
--Michi

On Thu, May 10, 2012 at 4:11 PM, Jonathan Simms <[EMAIL PROTECTED]> wrote:
> Michi, fair point, I actually just looked into it, there doesn't seem
> to be a way through the api to re-establish the session. If you call
> zookeeper_close on the handle:
>
>  "After this call, the client session will no longer be valid. The
> function will flush any outstanding send requests before return. As a
> result it may block."
>
> I tried:
>
> * establish session with handle A
> * copy clientid_t from handle A
> * zookeeper_close handle A
> * construct handle B using clientid_t values from handle A
>
> I get back a SESSION_EXPIRED from the server. (debug from mt lib here:
> https://gist.github.com/3b7e4060746d03cef287)
>
> It would be *really* useful if i could basically "suspend" a session
> while i forked, then reconnect and pick up where i left off. Is this
> not possible?
>
> On Thu, May 10, 2012 at 6:41 PM, Michi Mutsuzaki <[EMAIL PROTECTED]> wrote:
>> Hi Jonathan,
>>
>> It would be very difficult to share multi-threaded zk handle with
>> child process. I'm surprised it actually works on mac. I think saving
>> session id/password and re-establishing the session in the child
>> process is more robust and platform independent.
>>
>> Thanks!
>> --Michi
>
>
>>
>> On Thu, May 10, 2012 at 12:45 PM, Jonathan Simms <[EMAIL PROTECTED]> wrote:
>>> Hi all,
>>>
>>> I'm the maintainer of the ruby zookeeper library, and I'm having
>>> trouble getting consistent behavior when a user calls fork(). When
>>> developing it on MacOS (using 3.3.5), I was able to fork, then
>>> immediately call zookeeper_close() in the child, and then create a new
>>> handle. Testing on Linux, the behavior is much more unpredictable.
>>> Regularly, it seems there are segfaults when calling zookeeper_close.
>>> https://gist.github.com/22338464cd47e0e50970
>>>
>>>
>>> So I guess my question is, is there any safe way to fork() while the
>>> client is running?
>>>
>>> Another possibility i thought of is to note the session id/passwd,
>>> close the client, fork, then re-open with the same id/passwd to
>>> re-establish the session in the parent.
>>>
>>> Any recommendations?