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 # user >> Re: exposing lastSend


On 11 July 2014 10:31, Miller, Austin <[EMAIL PROTECTED]>
wrote:
Pings, from an idle client, actually need to go out every 1/3 of
negotiatedSessionTimeout.
1/3 of negotiatedSessionTimeout will already cause a ConnectionLoss...
No, the ZK server *will* RST the client of if it hasn't ping in 1/3 of
negotiatedSessionTimeout.

You could just release the lock as soon as you receive ConnectionLoss
(i.e.: without waiting for SessionExpired, which you'll only get upon
reconnecting to a ZK server.. which could take longer, given a partition or
loaded network). But the case you are exposing is conflated with the
pathological scenario of a JVM instance starving it's threads... if that's
a risk, you might as well have an external health-check process that kills
your JVM entirely once  it's likely that the ZK thread might be starving
(hence, losing your lock being more likely).
-rgs

 
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