This is an automated email from the ASF dual-hosted git repository. tison pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/curator-site.git
commit ed363e7f9248dc349ae8bd52b764f056e90f2faf Author: tison <[email protected]> AuthorDate: Tue Aug 15 16:32:41 2023 +0800 fix: broken link to wiki.apache.org Signed-off-by: tison <[email protected]> --- docs/errors.md | 4 ++-- docs/tech-note-03.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/errors.md b/docs/errors.md index fe9a1cd..1b4af91 100644 --- a/docs/errors.md +++ b/docs/errors.md @@ -4,7 +4,7 @@ ZooKeeper is a very low level system that requires users to do a lot of housekeeping. See: -* https://wiki.apache.org/hadoop/ZooKeeper/FAQ +* https://cwiki.apache.org/confluence/display/ZOOKEEPER/FAQ The Curator [Framework](framework.md) is designed to hide as much of the details/tedium of this housekeeping as is possible. @@ -26,7 +26,7 @@ Curator exposes several listenable interfaces for clients to monitor the state o | State Change | Description [...] |--------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [...] | CONNECTED | Sent for the first successful connection to the server. NOTE: You will only get one of these messages for any CuratorFramework instance. [...] -| READONLY | The connection has gone into read-only mode. This can only happen if you pass true for CuratorFrameworkFactory.Builder.canBeReadOnly(). See the ZooKeeper doc regarding read only connections: https://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode. The connection will remain in read only mode until another state change is sent. [...] +| READONLY | The connection has gone into read-only mode. This can only happen if you pass true for CuratorFrameworkFactory.Builder.canBeReadOnly(). See the ZooKeeper doc regarding read only connections: https://cwiki.apache.org/confluence/display/HADOOP2/ZooKeeper+GSoCReadOnlyMode. The connection will remain in read only mode until another state change is sent. [...] | SUSPENDED | There has been a loss of connection. Leaders, locks, etc. should suspend until the connection is re-established. [...] | RECONNECTED | A suspended or lost connection has been re-established. [...] | LOST | Curator will set the LOST state when it believes that the ZooKeeper session has expired. ZooKeeper connections have a session. When the session expires, clients must take appropriate action. In Curator, this is complicated by the fact that Curator internally manages the ZooKeeper connection. Curator will set the LOST state when any of the following occurs: a) ZooKeeper returns a Watcher.Event.KeeperState.Expired or KeeperException.Code.SESSIONEXPIRED; b) Curator closes t [...] diff --git a/docs/tech-note-03.md b/docs/tech-note-03.md index f28e793..2f32e4e 100644 --- a/docs/tech-note-03.md +++ b/docs/tech-note-03.md @@ -4,7 +4,7 @@ Dealing with session failure. ## Details -ZooKeeper's 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 +ZooKeeper's 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: https://cwiki.apache.org/confluence/display/ZOOKEEPER/FAQ 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.
