Service Configuration and Coordination - Real-Time Analytics - page 65

with a timeout of 1000 milliseconds and a maximum of three tries. This
policy retries connection attempts with increasingly longer waits between
attempts.
Curator has several other retry policies available for use. The RetryNTimes
policy is like the ExponentialBackoff policy, except that it waits the
same amount of time between attempts instead of increasing the wait. The
RetryUntilElapsed waits a fixed amount of time between retries, like
the RetryNTimes policy. The difference is that it continues trying until a
certainamountoftimehaselapsedinsteadoftryingafixednumberoftimes.
The CuratorFrameworkFactory class can also return a connection
Builder class instead of immediately creating the client. This is useful
when using some of Curator's advanced features. The previously described
connection looks like this with the Builder method:
CuratorFrameworkFactory.Builder builder =
CuratorFrameworkFactory. builder ()
.connectString("localhost:2181")
.retryPolicy( new ExponentialBackoffRetry(1000,3));
In addition to the basic connection string and retry policy, the connection
can be allowed to enter a read-only state in the case of a network partition
with the canBeReadOnly method:
builder.canBeReadOnly(true);
A namespace, which is prepended to all paths, can be set using the
namespace method:
builder.namespace("subspace");
Finally, to create the CuratorFramework object, call the build method:
CuratorFramework client = builder.build();
After the CuratorFramework object has been created, the connection
must be started using the start method. Most of the CuratorFramework
methods will not work if the connection has not been started.