curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: How does CuratorFramework handle connection losses?
Date Wed, 22 Mar 2017 21:47:28 GMT
This would make a nice tech note on the wiki if anyone's up to it.

-Jordan

> On Mar 22, 2017, at 4:13 PM, Cameron McKenzie <cammckenzie@apache.org> wrote:
> 
> 1.) Calling close() will just clean up any resources associated with the CuratorFramework
(Zookeeper connection's etc.). If your application exits without calling close(), this will
not cause any issues.
> 
> 2.) InterProcessMutex's are implemented using an ephemeral node in Zookeeper. If your
client dies without releasing the mutex then this ephemeral node will be removed after the
session times out. So, yes, after your specified session timeout other clients will be able
to acquire the mutex.
> 
> 3.) SUSPENDED occur as soon as the connection loss to ZK is determined. The LOST event
differs depending on which version of Curator you're using. In Curator 2.x lost will occur
once all of the retries have occurred (based on your specified retry policy). In Curator 3.x,
Curator will simulate server side session loss, by starting a timer upon receiving the SUSPENDED
event, and then publish a LOST event once the session timeout has been reached.
> 
> The RECONNECTED event will occur once a connection has been reestablished to ZK. You
can rely on Curator reconnecting when it is possible to do so.
> cheers
> 
> On Thu, Mar 23, 2017 at 4:30 AM, Benson Qiu <qiu.benson@gmail.com <mailto:qiu.benson@gmail.com>>
wrote:
> Hi,
> 
> Several questions:
> 
> 1. The CuratorFramework documentation <http://curator.apache.org/curator-framework/>
says that "should share one CuratorFramework per ZooKeeper cluster in your application". I
create an instance and call CuratorFramework#start() on application startup and reuse the
same instance throughout the lifetime of my application, but I never call CuratorFramework#close().
Is this bad practice? What happens if my application periodically killed and restarted?
> 
> 2. If I acquire an InterProcessMutex and my application is killed before I call InterProcessMutex#release(),
what happens? Based on my experiments with TestingServer, it seems that after DEFAULT_SESSION_TIMEOUT_MS
<https://github.com/apache/curator/blob/022de3921a120c6f86cc6e21442327cc04b66cd2/curator-framework/src/main/java/org/apache/curator/framework/CuratorFrameworkFactory.java#L51>,
other applications are able to acquire the InterProcessMutex with the same lock path. So there
might be temporary starvation, but no deadlock. Is my understanding correct?
> 
> 3. I did a quick experiment where I pulled out my ethernet cable (lost connection to
the remote ZK cluster), waited several minutes, and then inserted my ethernet cable in again.
I observed from ConnectionStateListener that the state will change to SUSPENDED, then LOST,
and when the ethernet cable is inserted again, RECONNECTED. How long does it take for each
state change to happen? Even if I lose connection for a long period of time, can I trust that
CuratorFramework will always handle reconnecting?
> 
> Any help, even if it's on a subset of these questions, would be really appreciated!
> 
> Thanks,
> Benson
> 


Mime
View raw message