zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohammad Shamma <mohammadsha...@gmail.com>
Subject Re: zookeeper client session write-read consistency
Date Wed, 20 Nov 2013 22:31:36 GMT
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 <
german.blanco.blanco@gmail.com> 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 <
> german.blanco.blanco@gmail.com> 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 <
> 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
> >>
> >
> >
>



-- 
Mohammad Shamma

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