These are chat archives for RBMHTechnology/eventuate

15th
Feb 2018
Volker Stampa
@volkerstampa
Feb 15 2018 16:31
Sorry for the late reply. TBH I am not really into the CRDT part of eventuate, so I am not sure if I can help. I actually wonder if extending the replication protocol is really required. If it is we should at least make sure that rolling upgrades are supported. Maybe you could elaborate a little more on why you need to send replicaVersionVectors around given that those are just cached versions of the version vectors of remote logs. Shouldn't the remote log already have this information?
gabrielgiussi
@gabrielgiussi
Feb 15 2018 19:41

Thanks for your help Volker.

Shouldn't the remote log already have this information

This is true but only for dense replication networks, not for sparse like
sparse
I've tried to get the information that I need from ReplicationWrites but without success, I mean that C and B get the CTVV from each other through the ReplicationWrite sent by A but it doesn't work.

gabrielgiussi
@gabrielgiussi
Feb 15 2018 20:24
What I really need is the CTVV of each one of the partitions of the log to emit TCStable. For example, in endpoint B, when he knows that the CTVV of A and C are (a -> 0, b -> 1, c -> 0), it can emit a local TCStable(0,1,0).
At first I was taking the ctvv of the ReplicationRead and this worked except for sparse networks.
gabrielgiussi
@gabrielgiussi
Feb 15 2018 22:30
Stability in CRDT is an optimization because is used to prune the size of the ops, hence is doesn't have low latency requirements like replicaton does. Maybe it would be better to keep the ReplicationProtocol unchanged and send scheduled ReplicaVersionVectors from EventLog to remote Replicator (with a default of 1 minute perhaps).