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?
