These are chat archives for RBMHTechnology/eventuate

18th
Apr 2017
gabrielgiussi
@gabrielgiussi
Apr 18 2017 12:45
So if I've understood correctly, whether the solution is blocking or non-blocking depends on if causality violations could occur. In the first generation solution (3.1) causality violations couldn't occur because each event replication carries ALL the events on its causal past, wich means a huge impact on network usage but the events could always be delivered. On the other hand in the vector clock solution (3.2) causality violations could occur, hence the need to buffer events until the causal past is received, wich means less network usage at the cost of having to block events delivery.
I've tried to represent what would be happening in your example with the current approach:
non blocking.
Is it correct?
Martin Krasser
@krasserm
Apr 18 2017 14:19
Yes, this looks good
Martin Krasser
@krasserm
Apr 18 2017 14:24

Regarding

... (3.1) causality violations couldn't occur because each event replication carries ALL the events on its causal past

AFAIR, the naive non-blocking algorithm doesn't redundantly multicast all events from the causal past but only those that have been causally delivery (to the local) since the last multicast (which may still be many though).

gabrielgiussi
@gabrielgiussi
Apr 18 2017 15:04
Great. A final question if I may, this solution requires that each node keeps track of the list of events and its corresponding vector clock (e.g. DC2 should hold the list of E2 and E3 with its vector clocks to be able to do the causality filter when it receives the replication request from DC3 with (1,0,0)). Does Eventuate resolve when an event was seen by all nodes to clear this list of vector clock -> event?
Martin Krasser
@krasserm
Apr 18 2017 15:29
This is called causal stability but not implemented yet. See also RBMHTechnology/eventuate#301. And ... we love pull requests :grinning:
gabrielgiussi
@gabrielgiussi
Apr 18 2017 15:44
True, I remember had talked with you about a Stable(timestamp) event that should be delivered to CRDTActor's that were pure op based in order to "discard timestamp information for elements once they become stable" and reduce the state of CRDTs. I'll take a look to causal stability to see if I can help.
Thanks for all the detailed responses.
Martin Krasser
@krasserm
Apr 18 2017 16:14
You're welcome.