These are chat archives for atomix/atomix
KeepAliveRequests. I believe that alone can be used to determine whether a faulty client is blocked on events. When a
KeepAliveEntryis applied to the state machine, the entry’s
completeIndexare stored in the session. If a client submits two keep-alives in a row where the
eventIndexis greater than the
completeIndexof both keep-alives are identical (
completeIndexhas not increased as it should have), we assume the client is blocked and expire the session. Because we know the client has received events up to
completeIndexis less than
eventIndexthe client is still processing those events, we can assume two keep-alives with the same
completeIndexindicates a faulty client if the
completeIndexshould have increased. This effectively gives event listeners a session timeout to complete handling of events.
Eventobject rather than the event value. I'm still not totally sure about this change. What the
Eventinterface has is a
completemethod that's basically an ack. So, the
completeIndexis increased when all listeners for an event
complete()the event. A long-running listener can immediately
complete()an event to prevent the cluster from being blocked and can continue on doing whatever it wants in another thread or a thread pool can be set on the client for event listeners. This may force the user to think about an event listener's impact on the progression of the cluster. If a command is submitted with linearizable consistency for events, the command is effectively blocked until the events are acked. I suppose the alternative is removing the
complete()method and considering events to be acknowledged once the listener is called, but having an ack method allows clients to do other things with the event before it's considered completed
complete()method does make it easier to write a faulty client simply by not acking events
joincommand can complete without all nodes actually being notified of the new member, and that can produce other consistency issues. At least if it’s completed in the event thread we have ensured the thread is not blocked at that point
completeIndexat all and no need to expire sessions that have blocked event listeners.
complete()method allows user code to handle events asynchronously if necessary
here it is:
This implies that an event is on the way to the client, but may not reach the client before the successful return code to the change operation reaches the client that initiated the change. Watches are sent asynchronously to watchers. ZooKeeper provides an ordering guarantee: a client will never see a change for which it has set a watch until it first sees the watch event. Network delays or other factors may cause different clients to see watches and return codes from updates at different times. The key point is that everything seen by the different clients will have a consistent order.
Note that if there is a change to /a between the asynchronous read and the synchronous read, the client library will receive the watch event saying /a changed before the response for the synchronous read, but because the completion callback is blocking the event queue, the synchronous read will return with the new value of /a before the watch event is processed.
SEQUENTIALcan be made the default
SEQUENTIALevents. Commands and events are sequenced separately. In other words, if client A submits command
1to the cluster which triggers a event
1, and client B submits command
2to the cluster, client B may see command
2complete before it receives event
if there is a change to /a between the asynchronous read and the synchronous read, the client library will receive the watch event saying /a changed before the response for the synchronous read
2to the cluster and it shouldn’t see command
2complete before it has received event
1. I’m not sure what coordination is necessary for the client to know it should have received event
1. It seems to be a contract that can be enforced on a client with some feedback from the cluster perhaps in the command response.
LINEARIZABLEwith something more practical than adding a bunch of synchronous round trips to operations.
SEQUENTIALmodel, the gaurantee is events will be observed in the same order at all clients. But no guarantees are provided regarding the timing, right?
1and client B submits command
2, then B’s command can complete before it sees the event for A’s command. Is that right?