hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Hadoop Wiki] Update of "ZooKeeper/FAQ" by BenjaminReed
Date Fri, 08 May 2009 21:51:58 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change notification.

The following page has been changed by BenjaminReed:

  In the case of testing we want to cause a problem, so to explicitly expire a session an
application connects to ZooKeeper, saves the session id and password, creates another ZooKeeper
handle with that id and password, and then closes the new handle. Since both handles reference
the same session, the close on second handle will invalidate the session causing a SESSION_EXPIRED
on the first handle.
+ [[BR]]
+ [[Anchor(5)]]
+ '''5. [#5 Why doesn't the NodeChildrenChanged and NodeDataChanged watch events return more
information about the change?]'''
+ When a ZooKeeper server generates the change events, it knows exactly what the change is.
In our initial implementation of ZooKeeper we returned this information with the change event,
but it turned out that it was impossible to use correctly. There may be a correct way to use
it, but we have never seen a case of correct usage. The problem is that watches are used to
find out about the latest change. (Otherwise, you would just do periodic gets.) The thing
that most programmers seem to miss, when they ask for this feature, is that watches are one
time triggers. Observe the following case of data change: a process does a getData on "/a"
with watch set to true and gets "v1", another process changes "/a" to "v2" and shortly there
after changes "/a" to "v3". The first process would see that "/a" was changed to "v2", but
wouldn't know that "/a" is now "/v3".

View raw message