[ https://issues.apache.org/jira/browse/ZOOKEEPER-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798906#action_12798906 ]
Henry Robinson commented on ZOOKEEPER-641: ------------------------------------------ This would be a great documentation patch - please do consider writing it up and submitting it. Logically, the idea of presence notification is distinct from the service metadata, as you might want groups containing things other than services. So it's probably best to use services as an example, rather than the only motivation for presence notification. > Improve details about group membership recipe > --------------------------------------------- > > Key: ZOOKEEPER-641 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-641 > Project: Zookeeper > Issue Type: Improvement > Components: documentation > Affects Versions: 3.2.1 > Reporter: Adam Rosien > Fix For: 3.3.0 > > > Regarding > http://eng.kaching.com/2010/01/actually-implementing-group-management.html > Patrick Hunt asked for a more complete group membership recipe from the one > listed at > http://hadoop.apache.org/zookeeper/docs/r3.0.0/recipes.html#sc_outOfTheBox. > The relevant text from the blog post: > One type of group management system using ZooKeeper: > * A group contains some logical service. The *meaning* of belonging to a > group is typically "the instance is available for use by clients over the > network". > * Services can join and leave the group. The special case of a service > crashing or a network outage needs to be handled as leaving the group. > * Joined services share metadata about how to communicate with it, i.e., > its IP address, base URL, etc. > * Clients can ask what instances are in the group, i.e., available. > * Clients are notified when group membership changes so they can mutate > their local state. > These map onto ZooKeeper as: > * A group is a (permanent) node in the ZooKeeper hierarchy. Clients and > services must be told the path to this node. > * A services joins the group by creating an ephemeral node whose parent > is the group node. By using an ephemeral node, if the service dies then the > service is automatically removed from the group. > * The ephemeral node's data contains the service metadata in some format > like JSON, XML, Avro, Protobufs, Thrift, etc. ZooKeeper has no equivalent of > HTTP's "Content-Type" header to identify the metadata representation, so > services and clients must agree upon the format in some manner. > * Clients can query for the children of the group node to identify the > members of the group. > * Clients can place a watch on the group node to be notified if nodes > have joined or left the group. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.