This looks like a bug. Does this happen without doing any reads/writes using
the zookeeper handle?
Please do open a jira for this.
Thanks
mahadev
On 8/2/09 10:53 PM, Michi Mutsuzaki mi...@cs.stanford.edu wrote:
Hello,
I'm doing something like this (using zookeeper-3.2.0):
zhandle_t*
Please do enter a JIRA. Looking at the source it seems that we log and
error, but the calling code continues. I think this is happening because
the chroot c lib code is not handling znode watches separate from state
change notifications.
The calling code just continues after logging an
Flavio,
I notice that you've updated the patches referenced for the WAN
deployment. There appears to be an order dependency w/ respect to these
four patches...
ZOOKEEPER-473.patch ZOOKEEPER-479-branch3.2.patch
ZOOKEEPER-481-branch3.2.patch ZOOKEEPER-491.patch
473 - 479 (479 fails)
Another problem...I've reverted to the latest versions of the patches
that are not specific to branch-3.2, and I'm getting two compilation
errors:
build-generated:
[javac] Compiling 44 source files to
/home/toddg/asi/workspaces/main/Main/RSI/etc/holmes/main/zookeeper/src/p
That'd be perfect. Thanks!
-Original Message-
From: Mahadev Konar [mailto:maha...@yahoo-inc.com]
Sent: Monday, August 03, 2009 4:24 PM
To: zookeeper-user@hadoop.apache.org
Subject: Re: Unending Leader Elections in WAN deploy
Hi Todd,
Most of the patches that you mention should
I assume you are calling the synchronous version of exists. The callbacks for
both the watches and async calls are processed by a callback thread, so the
ordering is strict. Synchronous call responses are not queued to the callback
thread. (this allows you to make synchronous calls in callbacks
