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 >
