-
Notifications
You must be signed in to change notification settings - Fork 434
Tech Note 3
Dealing with session failure.
ZooKeeper clients maintain a session with the server ensemble. Ephemeral nodes are tied to this session. When writing ZooKeeper-based applications you must deal with session expirations (due to network partitions, server crashes, etc.). This ZooKeeper FAQ discusses it: http://wiki.apache.org/hadoop/ZooKeeper/FAQ#A3
For the most part, Curator shields you from the details of session management. However, Curator’s behavior can be modified. By default, Curator treats session failures the same way that it treats connection failures: i.e. the current retry policy is checked and, if permitted, operations are retried.
There are use-cases, though, where a series of operations must be tied to the ZooKeeper session. For example, an ephemeral node is created as a kind of marker then several other ZooKeeper operations are performed. If the session were to fail at any point, the entire operation should fail. Curator’s default behavior doesn’t do this. When you need this behavior, use:
SessionFailRetryLoop
This is similar to the standard retry loop but if a session fails, any future Curator methods (in the same thread) will also fail.
- Curator
- Javadoc
- Coverage Report
- Getting Started
- Examples
- FAQ
- Client
- Framework
-
Recipes
- Leader Latch
- Leader Election
- Shared Reentrant Lock
- Shared Lock
- Shared Reentrant Read Write Lock
- Shared Semaphore
- Multi Shared Lock
- Distributed Queue
- Distributed Id Queue
- Distributed Priority Queue
- Distributed Delay Queue
- Simple Distributed Queue
- Barrier
- Double Barrier
- Shared counter
- Distributed Atomic Long
- Path Cache
- Node Cache
- Utilities – Test Server, Test Cluster, ZKPaths, EnsurePath, QueueSharder, Reaper, ChildReaper
- Tech Notes
- Errors
- Exhibitor Integration
- Extensions
- Logging and Tracing