ZooKeeper C bindings and cygwin?

2010-09-01 Thread jdeinh...@ujam.com
Dear list readers, we want to use the zookeeper C bindings with our applications. Some of them are running on Linux (e.g. Load Balancer) and others (.NET(C#) Audio Servers) on Windows Server 2008. We'd like to try using cygwin to accomplish this task on windows, but we need further advice on

Re: ZooKeeper C bindings and cygwin?

2010-09-01 Thread jdeinh...@ujam.com
Dear list readers, we've solved the problem ourself. We found the dll CYGZOOKEEPER_MT-2.DLL in /usr/local/bin. Best regards Jan Jan Am 01.09.2010 um 12:57 schrieb jdeinh...@ujam.commailto:jdeinh...@ujam.com: Dear list readers, we want to use the zookeeper C bindings with our applications.

Re: closing session on socket close vs waiting for timeout

2010-09-01 Thread Benjamin Reed
i'm a bit skeptical that this is going to work out properly. a server may receive a socket reset even though the client is still alive: 1) client sends a request to a server 2) client is partitioned from the server 3) server starts trying to send response 4) client reconnects to a different

Re: closing session on socket close vs waiting for timeout

2010-09-01 Thread Patrick Hunt
Ben, in this case the session would be tied directly to the connection, we'd explicitly deny session re-establishment for this session type (so 4 would fail). Would that address your concern, others? Patrick On 09/01/2010 10:03 AM, Benjamin Reed wrote: i'm a bit skeptical that this is going

RE: closing session on socket close vs waiting for timeout

2010-09-01 Thread Fournier, Camille F. [Tech]
Hmm. Tying the session directly to the connection basically reverses my problem: I used to have crashed clients' ephemeral nodes visible for the duration of the session timeout, now I have partitioned clients' ephemeral nodes doubled for the duration of the session timeout. Of course, I expect

Re: closing session on socket close vs waiting for timeout

2010-09-01 Thread Patrick Hunt
On 09/01/2010 01:40 PM, Fournier, Camille F. [Tech] wrote: Hmm. Tying the session directly to the connection basically reverses my problem: I used to have crashed clients' ephemeral nodes visible for the duration of the session timeout, now I have partitioned clients' ephemeral nodes doubled