Guaranteed message delivery until session timeout?

2010-06-30 Thread Bryan Thompson
Hello,

I am wondering what guarantees (if any) zookeeper provides for reliable 
messaging for operation return codes up to a session timeout.  Basically, I 
would like to know whether a zookeeper client can rely on observing the return 
code for a successful operation which creates an ephemeral (or ephemeral 
sequential) znode -or- have a guarantee that its session was timed out and the 
ephemeral znode destroyed.  That is, does zookeeper provide guaranteed delivery 
of the operation return code unless the session is invalidated by a timeout?

Thanks,
Bryan


Re: Guaranteed message delivery until session timeout?

2010-06-30 Thread Ted Dunning
Which API are you talking about?  C?

I think that the difference between connection loss and session expiration
might mess you up slightly in your disjunction here.

On Wed, Jun 30, 2010 at 7:45 AM, Bryan Thompson br...@systap.com wrote:

 Hello,

 I am wondering what guarantees (if any) zookeeper provides for reliable
 messaging for operation return codes up to a session timeout.  Basically, I
 would like to know whether a zookeeper client can rely on observing the
 return code for a successful operation which creates an ephemeral (or
 ephemeral sequential) znode -or- have a guarantee that its session was timed
 out and the ephemeral znode destroyed.  That is, does zookeeper provide
 guaranteed delivery of the operation return code unless the session is
 invalidated by a timeout?

 Thanks,
 Bryan



Re: Guaranteed message delivery until session timeout?

2010-06-30 Thread Ted Dunning
Isn't this the same question that you sent this morning?

On Wed, Jun 30, 2010 at 3:36 PM, Bryan Thompson br...@systap.com wrote:

 Hello,

 I am wondering what guarantees (if any) zookeeper provides for reliable
 messaging for operation return codes up to a session timeout.  Basically, I
 would like to know whether a zookeeper client can rely on observing the
 return code for a successful operation which creates an ephemeral (or
 ephemeral sequential) znode -or- have a guarantee that its session was timed
 out and the ephemeral znode destroyed.  That is, does zookeeper provide
 guaranteed delivery of the operation return code unless the session is
 invalidated by a timeout?

 Thanks,
 Bryan



Re: Guaranteed message delivery until session timeout?

2010-06-30 Thread Patrick Hunt

On 06/30/2010 09:37 AM, Ted Dunning wrote:

Which API are you talking about?  C?

I think that the difference between connection loss and session expiration
might mess you up slightly in your disjunction here.

On Wed, Jun 30, 2010 at 7:45 AM, Bryan Thompsonbr...@systap.com  wrote:


I am wondering what guarantees (if any) zookeeper provides for reliable
messaging for operation return codes up to a session timeout.  Basically, I


in particular see timeliness 
http://hadoop.apache.org/zookeeper/docs/current/zookeeperProgrammers.html#ch_zkGuarantees



would like to know whether a zookeeper client can rely on observing the
return code for a successful operation which creates an ephemeral (or
ephemeral sequential) znode -or- have a guarantee that its session was timed
out and the ephemeral znode destroyed.  That is, does zookeeper provide


Any ephemeral node(s) associated with a session will be deleted when the 
session is invalidated (session expiration or client close request).


Patrick


Re: Guaranteed message delivery until session timeout?

2010-06-30 Thread Ted Dunning
Also this:

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 ph...@apache.org wrote:

 in particular see timeliness
 http://hadoop.apache.org/zookeeper/docs/current/zookeeperProgrammers.html#ch_zkGuarantees



Re: Guaranteed message delivery until session timeout?

2010-06-30 Thread Ted Dunning
Yes.  That is true.  In particular, your link to a server (or the server
itself) can fail causing your client to switch to a different ZK server and
retry there.  This can and often does happen without you knowing.

On Wed, Jun 30, 2010 at 4:48 PM, Bryan Thompson br...@systap.com wrote:

 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?



Re: Guaranteed message delivery until session timeout?

2010-06-30 Thread Ted Dunning
I think that you are correct, but a real ZK person should answer this.

On Wed, Jun 30, 2010 at 4:48 PM, Bryan Thompson br...@systap.com wrote:

 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?