Can a zookeeper client be made to influence the client-to-server heartbeats?

[Sasi <sa...@gmail.com>]

In distributed systems that uses Apache Zookeeper for co-ordination, each
component is a client to the Zookeeper server, and it instantiates a
zookeeper instance, which in the background is sending heartbeats to the
zookeeper server. I understand that the time interval for heartbeat
communication is configurable. In situations when the "component" itself
goes into a "faulty" state but the "heartbeats" to zookeeper is good and
unaffected, proper state of this component is not communicated to the rest
of the components in the system.

Is it possible out of the box, to influence the heartbeat mechanism -
typically by passing a "status reporting function" to the zookeeper instance
- to "validate" the status of the component before sending the heartbeat ?



--
View this message in context: http://zookeeper-user.578899.n2.nabble.com/Can-a-zookeeper-client-be-made-to-influence-the-client-to-server-heartbeats-tp7580099.html
Sent from the zookeeper-user mailing list archive at Nabble.com.

RE: Can a zookeeper client be made to influence the client-to-server heartbeats?

[Rakesh R <ra...@huawei.com>]

Adding one more point...

ZooKeeper heartbeat is actually used to show the liveliness of the zkclient-zkserver communication and there is no handle exposed to the application.

Also, one can think of alternatives like - application can create znode to maintain its health status. He can update his status into this health znode during fault. On the other side the interested clients can watch this and act upon.

-Rakesh

-----Original Message-----
From: Raúl Gutiérrez Segalés [mailto:rgs@itevenworks.net] 
Sent: 08 July 2014 10:51
To: user@zookeeper.apache.org
Cc: zookeeper-user@hadoop.apache.org
Subject: Re: Can a zookeeper client be made to influence the client-to-server heartbeats?

On 7 July 2014 18:39, Sasi <sa...@gmail.com> wrote:

> In distributed systems that uses Apache Zookeeper for co-ordination, 
> each component is a client to the Zookeeper server, and it 
> instantiates a zookeeper instance, which in the background is sending 
> heartbeats to the zookeeper server. I understand that the time 
> interval for heartbeat communication is configurable. In situations 
> when the "component" itself goes into a "faulty" state but the 
> "heartbeats" to zookeeper is good and unaffected, proper state of this 
> component is not communicated to the rest of the components in the system.
>
> Is it possible out of the box, to influence the heartbeat mechanism - 
> typically by passing a "status reporting function" to the zookeeper 
> instance
> - to "validate" the status of the component before sending the heartbeat ?
>

I don't think so — pings are hard-coded into the protocol and you can't add payload to them. You'd probably be better off having a thread which does the health-check of your component and then kills the ZK session if the health-check failed.


-rgs

Re: Can a zookeeper client be made to influence the client-to-server heartbeats?

[Raúl Gutiérrez Segalés <rg...@itevenworks.net>]

On 7 July 2014 18:39, Sasi <sa...@gmail.com> wrote:

> In distributed systems that uses Apache Zookeeper for co-ordination, each
> component is a client to the Zookeeper server, and it instantiates a
> zookeeper instance, which in the background is sending heartbeats to the
> zookeeper server. I understand that the time interval for heartbeat
> communication is configurable. In situations when the "component" itself
> goes into a "faulty" state but the "heartbeats" to zookeeper is good and
> unaffected, proper state of this component is not communicated to the rest
> of the components in the system.
>
> Is it possible out of the box, to influence the heartbeat mechanism -
> typically by passing a "status reporting function" to the zookeeper
> instance
> - to "validate" the status of the component before sending the heartbeat ?
>

I don't think so — pings are hard-coded into the protocol and you can't add
payload to them. You'd probably be better off having a thread which does
the health-check of your component and then kills the ZK session if the
health-check failed.


-rgs