zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shraer <shra...@gmail.com>
Subject Re: Doubts about libzookeeper
Date Tue, 04 Aug 2015 16:52:05 GMT
Hi Camille,

if the client received a response for the delete then sure it shouldn't be
able to connect
to servers that didn't see it. But if it disconnected before seeing the
response the example seems possible to me.
I haven't checked the code to see when exactly the transaction number is
incremented at
the client, so I may be wrong, but suppose for example that zkserver-1
crashes before
sending the delete request to the leader. Then, the request is gone
forever. If you don't let the client
connect to another server that hasn't seen the delete, the client will
never be able to connect.
So it seems quite possible that it connects, then the request is executed
(if zkserver-1 hasn't crashed
after all) and the znode disappears.

Alex


On Tue, Aug 4, 2015 at 8:33 AM, Camille Fournier <camille@apache.org> wrote:

> ZooKeeper provides a session-coherent single system image guarantee. Any
> request from the same session will see the results of all of its writes,
> regardless of which server it connects to. See:
>
> http://zookeeper.apache.org/doc/r3.4.6/zookeeperProgrammers.html#ch_zkGuarantees
>
> So, if your session deletes, and the delete is successfully processed by
> the quorum, you will not see the path that you have deleted no matter what
> server your session connects to. I believe in practice that this means that
> the ZK servers that might be behind your session (say server 2 is lagging
> behind a few commits) will refuse to allow your session to connect to it,
> so that you will not see stale data.
>
> This means that the example Lokesh gave:
>
> "1. Quorum leader has forwarded request to zkserver-2 for "delete /path".
> 2. If your client connects to "zkserver-2" after step 1 is executed (get
> /path). Then your "/path" will not be available.
> 3. If your client connects to "zkserver-2" before step1 is executed (get
> /path) then your "/path" would be available and after some time your path
> would not be available (after zkserver-2 is synched with the leader)"
>
> Cannot happen, so long as you are in the same session.
>
> C
>
> On Tue, Aug 4, 2015 at 6:49 AM, Lokesh Shrivastava <
> lokesh.shrivastava@gmail.com> wrote:
>
> > I think it depends on whether your request reaches zkserver-1 and whether
> > it is able to send the request to quorum leader. Considering that "delete
> > /path" request has reached the quorum leader then following may happen
> >
> > 1. Quorum leader has forwarded request to zkserver-2 for "delete /path".
> > 2. If your client connects to "zkserver-2" after step 1 is executed (get
> > /path). Then your "/path" will not be available.
> > 3. If your client connects to "zkserver-2" before step1 is executed (get
> > /path) then your "/path" would be available and after some time your path
> > would not be available (after zkserver-2 is synched with the leader)
> >
> > Others can correct me if this is not how it works.
> >
> > Thanks.
> > Lokesh
> >
> > On 4 August 2015 at 12:09, liangdong01@baidu.com <liangdong01@baidu.com>
> > wrote:
> >
> > > Hi,
> > >      I'm thinking about a program desgin with libzookeeper, here is my
> > > doubts:
> > >
> > >     1) first, I connnect to zkserver-1, and there exists the path
> > "/path".
> > >     2) I sends "delete /path", the request reaches(may not, i don't
> know
> > > about that) zkserver-1 and dont't know whether this effected, and then
> > lost
> > > connection before response returns.
> > >     3) reconnect the same session to zkserver-2,  and I sends "get
> > /path".
> > >
> > >     which one will the "get /path" return possibly :
> > >     1, "not exists"
> > >     2, "exists" and "always exists"
> > >     3, "exists" and "not exists" afterwards
> > >
> > >     my biggist problem is wether the 3) will occur or not, thanks!
> > >
> > >
> > >
> > >
> > > liangdong01@baidu.com
> > >
> >
>

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