Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # dev >> zookeeper_interest returning ZOK on Connection Loss


Copy link to this message
-
Re: zookeeper_interest returning ZOK on Connection Loss
Hi Yunong,

Yes, this looks like a bug. The problem is that the C client is not
handling the case when connect() returns EINPROGRESS or EWOULDBLOCK
and eventually fails. I think the right fix is to check SO_ERROR after
the socket becomes writable. Please go ahead and open a jira.

Thanks!
--Michi

On Sun, Nov 4, 2012 at 2:11 PM, Yunong Xiao <[EMAIL PROTECTED]> wrote:
> I have a fairly simple single-threaded C client set up -- single-threaded
> because we are embedding zk in the node.js/libuv runtime -- which consists of
> the following algorithm:
>
> zookeeper_interest(); select();
> // perform zookeeper api calls
> zookeeper_process();
>
> I've noticed that zookeeper_interest in the C client never returns error if it
> is unable to connect to the zk server.
>
> From the spec of the zookeeper_interest API, I see that zookeeper_interest is
> supposed to return ZCONNECTIONLOSS when disconnected from the client. However,
> digging into the code, I see that the client is making a non-blocking connect
> call
> https://github.com/apache/zookeeper/blob/trunk/src/c/src/zookeeper.c#L1596-1613
> ,  and returning ZOK
> https://github.com/apache/zookeeper/blob/trunk/src/c/src/zookeeper.c#L1684
>
> If we assume that the server is not up, this will mean that the subsequent
> select() call would return 0, since the fd is not ready, and future calls to
> zookeeper_interest will always return 0 and not the expected ZCONNECTIONLOSS.
> Thus an upstream client will never be aware that the connection is lost.
>
> I don't think this is the expected behavior. I have temporarily patched the zk
> C client such that zookeeper_interest will return ZCONNECTIONLOSS if it's still
> unable to connect after session_timeout has been exceeded.
>
> Is this the right interpretation of the API? Are you guys open to taking the
> patch I described?
>
> -Yunong
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB