zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From German Blanco <german.blanco.bla...@gmail.com>
Subject Re: zookeeper client session write-read consistency
Date Wed, 20 Nov 2013 07:01:41 GMT
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
<mohammadshamma@gmail.com>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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message