Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # user >> zookeeper client session write-read consistency


Copy link to this message
-
Re: zookeeper client session write-read consistency
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
>>
>
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB