On Mon, Jan 25, 2010 at 7:12 PM, Qing Yan <qing...@gmail.com> wrote:
> 2) Lose connection with the (quorum of) ZK cluster, e.g. C3 as mentioned
> before. if the situation continues will lead to CONNECTION_EXPIRE.
> About case 2), seems to me there is indeed a need for application to know
> about this, per ZK documentation :
> When you disconnect from a server (for example, when the server fails), you
> will not get any watches until the connection is reestablished. For this
> reason session events are sent to all outstanding watch handlers. Use
> session events to go into a safe mode: you will not be receiving events
> while disconnected, so your process should act conservatively in that mode.
> But from reading your post, it seems that case 2) will no longer be
> to application, hence the confusion.
I don't know if CONNECTION_LOSS would or would not be reported. As you
point out, it may well be important to report it or to report it after a
short period of loss without reconnection.
I think that my preference would be that transactions during a connection
loss block until the connection is restored or the session expires. That is
probably a matter of taste. Some people would probably prefer that most
operations return quickly even at the cost of considerably more complex
semantics on their part. Sequential creation, in particular, should
probably always block if the session is still conceivably alive.
In any case, I think the documentation needs to be updated to reflect the
> latest design/contract change.