Thanks for the reply, It turns out my observation of an inconsistent write/read was actually false. Digging further into the logs around the observed issue, I realized that the problem was actually a race condition in my code.
Thanks for explanation, it made me more confident in my understanding of zookeeper session consistency guarantees. On Tue, Nov 19, 2013 at 11:09 PM, German Blanco < [email protected]> wrote: > I for got one "within a session" in the previous text ... > ... This means that if a client sends a write *within a session*, AND no > other client modifies that information, it will always see the result of > that write in any subsequent read ... > > > On Wed, Nov 20, 2013 at 8:01 AM, German Blanco < > [email protected]> wrote: > > > hello, > > > > I believe that if you observe that, you should try to reproduce it > > with TRACE logging level and open a JIRA with the case sending the logs. > > If I am not wrong, ZooKeeper transactions are guaranteed to be executed > in > > sequential order in all servers and within the client session. This means > > that if a client sends a write, AND no other client modifies that > > information, it will always see the result of that write in any > subsequent > > read. > > This is true regardless of whether the client connects to one single > > server or needs to reconnect to another server of the quorum. The session > > may be kept when reconnecting, but the server checks that the last zxid > > seen by the client has also been seen by the server before allowing the > > connection. That means that if the client has made a write within that > > session, the server will only allow the connection if the write is > included > > in the server's transaction log. > > As you say, reads are not necessarily consistent, but that applies only > to > > different sessions connected to different servers. > > This is at least my view on your issue. > > /Germán. > > > > > > On Tue, Nov 19, 2013 at 9:51 PM, Mohammad Shamma < > [email protected] > > > wrote: > > > >> I have a question about the consistency guarantees of zookeeper. > >> > >> As far as I understand, zookeeper provides eventual consistency > >> guarantees. > >> Updates are not guaranteed to be seen by read operations following an > >> update (reads are not necessarily consistent). The reason behind this is > >> that reads might be served by a server that was not part of the quorum > >> that > >> approved of an update (and the server serving the read has not yet > >> received > >> the update). > >> > >> I have observed such write/read inconsistencies on operations within the > >> same client session. Is this behavior expected? This write/read > >> inconsistency is expected when the read and write are dispatched to > >> different servers, however it seems a bit odd that writes and reads that > >> are dispatched against the same server would be inconsistent. > >> > >> -- > >> Mohammad Shamma > >> > > > > > -- Mohammad Shamma
