On 11 July 2014 10:31, Miller, Austin <[EMAIL PROTECTED]>
Pings, from an idle client, actually need to go out every 1/3 of
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

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).

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