These are chat archives for RBMHTechnology/eventuate

19th
Feb 2018
Volker Stampa
@volkerstampa
Feb 19 2018 08:07
You are rigtht, without additional messages the RTM built at each location would lag a little bit behind. However I wonder, if this is a problem at all, given that this seems to be used for certain optimizations only and there are no low latency requirements? I also wonder if this all is an application level concern with the CRDTs being an application that runs on the distributed log. I.e. could it might make sense to integrate this in the CRDT logic instead of the log?
gabrielgiussi
@gabrielgiussi
Feb 19 2018 12:06

the RTM built at each location would lag a little bit behind

This is true, but the word little is a bit trickier. In this example it will lag until C writes a new event (C -> 2, A -> 1, B -> 1).
So in the worst scenario, if C is an endpoint that doesn't persist many events, the stabilization will lag dramatically.

I also wonder if this all is an application level concern

IMHO I think it is, stabilization is proper of the vector clocks used by the EventLog and it should be in the [core] module, CRDT's just use it for optimization.
Also, I implemented it there because I started using ReplicationRead & ReplicationWrite and replicaVersionVectorsafter, so I was forced. However, if we agree on a solution that doesn't need any of these and you think it should go in the [crdt] module, I could do it.

could it might make sense to integrate this in the CRDT logic instead of the log?

You mean like having an EventsourcedActor that receives all events and builds the RTM using the emittedId?
This is affected by the lag issue discussed above.