Yes, that is clear. I was looking for this:
> On some failures (communication errors, timeouts, etc) the client will not
> know if the update has applied or not. We take steps to minimize the
> failures, but the only guarantee is only present with successful return codes.
With regard to timeliness:
> The clients view of the system is guaranteed to be up-to-date within a
> certain time bound. (On the order of tens of seconds.) Either system changes
> will be seen by a client within this bound, or the client will detect a
> service outage.
This seems to imply that there are retries for transient communication
failures. Is that true?
For example, if a client registers a watch, and a state change which would
trigger that watch occurs _after_ the client has successfuly registered the
watch with the zookeeper quorum, is it possible that the client would not
observe the watch trigger due to communication failure, etc., even while the
clients session remains valid? It sounds like the answer is "no" per the
timeliness guarantee. Is that correct?
From: Ted Dunning [mailto:ted.dunn...@gmail.com]
Sent: Wednesday, June 30, 2010 7:38 PM
To: Patrick Hunt
Cc: email@example.com; Bryan Thompson
Subject: Re: Guaranteed message delivery until session timeout?
Once an update has been applied, it will persist from that time forward until a
client overwrites the update. This guarantee has two corollaries:
If a client gets a successful return code, the update will have been applied.
On some failures (communication errors, timeouts, etc) the client will not know
if the update has applied or not. We take steps to minimize the failures, but
the only guarantee is only present with successful return codes. (This is
called the monotonicity condition in Paxos.)
Any updates that are seen by the client, through a read request or successful
update, will never be rolled back when recovering from server failures.
I think that the clear implications here are:
a) if you get a successful return code and no session expiration, your
ephemeral file is there
b) if the ephemeral files is created, you might not get the successful return
code (due to connection loss), but the ephemeral file might continue to exist
(because connection loss != session loss)
c) if you get a failure return code, your ephemeral file was not created
On Wed, Jun 30, 2010 at 4:33 PM, Patrick Hunt
in particular see "timeliness"