Makes sense. Thanks for the detailed response Alexander! Em sex., 5 de mar. de 2021 às 13:49, Alexander Shraer <[email protected]> escreveu:
> Hi, > > It sounds tricky to rely on this, because the clocks aren't perfectly in > sync across the clients and servers and clock rates may drift. For example, > the way syncLimit is counted by the leader may be slower than how B > measures it, so the leader might not drop the connection before B's read > even if the connection is having issues. If you make enough assumptions > about the clocks and server processing speeds, e.g., set syncLimit (or the > time at which B reads) very conservatively then its probably ok. But it's > much better not to rely on this, and to have correctness independent of > timing assumptions. > > Alex > > > On Thu, Mar 4, 2021 at 6:59 AM Paulo Motta <[email protected]> > wrote: > > > Hi, > > > > ZooKeeper's documentation [1] mentions as Timeliness consistency > guarantee: > > > > --- > > The clients view of the system is guaranteed to be up-to-date within a > > certain time bound. (On the order of tens of seconds.) Either system > > changes will be seen by a client within this bound, or the client will > > detect a service outage. > > -- > > > > Can we safely assume this guarantee is governed by the syncLimit > > configuration property? That is, if a client A successfully writes to a > > znode /example at T0, and another client B successfully reads from > /example > > at T0 + syncLimit + 1 without any updates in between to this ZNode, > client > > B is *guaranteed* to read the value written by A, even without explicitly > > calling the *sync API*? > > > > Thanks, > > > > Paulo > > > > [1] https://zookeeper.apache.org/doc/r3.3.3/zookeeperProgrammers.html > > >
