Is the same client issuing the write and the read? If so, you should see the data you wrote. Otherwise, you may be connected to a lagging client, as Raul says.
C On Tue, Mar 4, 2014 at 3:22 PM, Raúl Gutiérrez Segalés <[email protected]>wrote: > On 4 March 2014 07:21, Brian Tarbox <[email protected]> wrote: > > > We're running a five node cluster in AWS and sometimes if I do a read > > immediately after doing a write ZK does not find the data I just wrote. > > > > I may just have a flawed model but is this a case of "writes go to the > > master, while reads can go to any node in the cluster?". We are thinking > > that perhaps our write went to the master and then our read went to a > > follower that hadn't gotten the write yet? > > > > Perhaps you can call sync() to ensure reads after writes? > > > > Along the same lines...when does a watch fire? After the leader has the > > change or after all followers have gotten the change? > > > > The pipeline is, in a poor's man diagram, as follow: > > > client → write request → zk_server_1 > ↓ > ↓ > write request is sent to the leader > ↓ > ↓ > leader fans out a transaction proposal to all followers > ↓ > ↓ > ↓ ↓ ↓ > ↓ > follower 1 follower 2 follower 3 follower 4 > ↓ > ↓ > followers, non-synchronously, acknowledge the proposal > ↓ > ↓ > when the leader gets a sufficient number of acks (from a "majority") > it fans out COMMIT msgs to followers > ↓ > ↓ > ↓ ↓ ↓ > ↓ > follower 1 follower 2 follower 3 follower 4 > ↓ > ↓ > followers will then apply the write which triggers watches, that in > turn will then flow to listening clients... > > > Hth, > -rgs >
