zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Kelly <iv...@apache.org>
Subject Re: zookeeper max no of children of znode
Date Sat, 27 Jun 2015 13:36:34 GMT
I assume you are talking about watchers here, because there is no guarantee
that if a client continually reads a node that it see each and every update.

In the case of watchers, you are only guaranteed to see any update from the
time you apply the watcher to the time you loose the connection to the
zookeeper session. When you loose the connection, on reconnection you
should do a read (getData or getChildren) to read any changes that may have
occurred while you were disconnected.

What design do you have in mind that you want to implement?


On Sat, Jun 27, 2015 at 1:39 PM Shushant Arora <shushantarora09@gmail.com>

> Say a client was connected to follower F1, And F1 was few seconds behind
> the leader. Then its connection got lost
> and session is transformed to follwer F2 which is in full sync with Leader.
> Then client will loose some updates ?
> Since now client will see latest state . All state changes between F1 lag
> to complete sync (F2)  are lost ?
> On Sat, Jun 27, 2015 at 4:17 PM, Ivan Kelly <ivank@apache.org> wrote:
> > Hi Shushant
> >
> > Is there any max number of children limit of a znode?
> > > As there is a limit of 1MB data of a znode.
> > >
> > There's no explicit limit to the number of children. However, there is a
> > limit to the size of the packet that can be sent back from the server in
> > response to getChildren which effectly ends up being the limit. This is
> > controls with a system property, jute.maxbuffer and defaults to 4MB (I
> > think you can get a around 200,000 znodes into this, though it also
> depends
> > on the length of the znode name).
> >
> >
> > > Does in zookeeper noodes which are behind the leader not accept the
> > > connection til they come in sync? If yes and only those nodes which are
> > in
> > > sync with leader accept the connection then How Zookeeper is eventual
> > > consistent, it should be fully consistent then since client will never
> > get
> > > connected to unsync nodes.
> > >
> > Once they have joined the quorum, all zookeeper nodes will accept client
> > connections. Followers are not guaranteed to be 100% in sync with the
> > leader, due to physics (messages take time to travel over the network).
> > However, a follower does guarantee that all clients connected will see
> all
> > updates in the same sequence that they occur on the server, and they
> should
> > only be a number of milliseconds behind. This isn't eventual consistency.
> > Thats what databases like cassandra do where all clients will eventually
> be
> > able to see all updates though the order it sees them can change.
> > ZooKeeper provides sequential consistency. However it only provides this
> > consistency within a single client session.
> >
> > -Ivan
> >

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