I don't see why clock must be in sync. They are counting time periods
(timeouts). Also note the difference between disconnected and session
expired events. This time difference is when client knows something's
wrong, but another client did not get a lock yet. You will have problems
if client can't
Hi Vitalii,
I don't see why clock must be in sync.
I don't see any reason to precisely sync the clocks either (but if we
could ... that would be wonderful.).
By *some constrains of clock drift*, I mean :
Every node has a clock, and all clocks increase at the same rate
or
the server’s clock
There are two events: disconnected and session expired. The ephemeral nodes
are removed after the second one. The client receives both. So to
implement at most one lock holder scheme, client owning lock must think
it've lost lock ownership since it've received disconnected event. So,
there is
Yes.
And in general, you can't have precise distributed lock control. There
will always be a bit of slop.
So decide which penalty is easier to pay. Do you want at-most-one or
at-least-one or something in between? You can't have exactly-one and
still deal with expected problems like partition
Hi Vitalii,
Thanks a lot, got your idea.
Suppose we are measuring the time of events outsides the system(zk clients) .
And we have no client side time tracking routine.
And t_i t_k if i k
t_0 :
client1 has created lock/node1, client2 has created lock/node2;
client1 thinks itself holding
Why would client 1s connection be unstable but client 2s not? In any normal
usage the ZK clients are going to be on the same network. Or, are you thinking
cross-data-center usage? In my opinion, ZooKeeper is not suited to cross data
center usage.
In any event, as others have pointed out,
Hi Jordan,
Why would client 1s connection be unstable but client 2s not? In any normal
usage the ZK clients are going to be on the same network. Or, are you
thinking cross-data-center usage? In my opinion, ZooKeeper is not suited to
cross data center usage.
er... the word unstable I used
sorry to jump in the middle, but i thought i'd point out a couple of things.
at the heart of ZK is Zab, which is an atomic broadcast protocol (it
actually has stronger guarantees than just atomic broadcast: it also
guarantees primary order). updates go through this protocol which
gives us
Benjamin,
thanks a lot, for your response and the great product you guys
designed and implemented.
these assumptions are manifest in ... the session timeouts of the clients.
Does this mean that session_expired event may be triggered all by
zk-client-library itself ?(by something like a
