These are chat archives for RBMHTechnology/eventuate

May 2017
Martin Krasser
May 02 2017 05:27
@mehdimas It became a lower priority for the projects I'm working on, so I personally can't give a timeframe at the moment. @volkerstampa any plans regarding that on your side?
Martin Krasser
May 02 2017 06:01

I can't understand when that updated version vector could arrive between a ReplicationRead and its corresponding ReplicationReadSuccess.

It may be updated during writes by a replication connection in the opposite direction.

Why EventLog.replicaVersionVectors is needed if ReplicationRead includes the currentVersionVector of the target?

See previous answer.

Why is fromSequenceNr included in ReplicationRead?

This is the tracked replication progress at target location. For example, after having replicated events 1-100 you want the next replication batch to start from 101 which is tracked with the fromSequenceNr.

I assumed that ReplicationRead only included currentVersionVector and then all (1) the events were causaly filtered

Replication read times would then linearly increase with the size of the log which must be avoided, of course.

I don't see what will be the benefit of causal stability

A causal stability indicator is needed for pure op-based CRDTs if you want to delete events from their local event logs. If you keep the whole op history persistent in local event logs then pure op-based CRDTs can be implemented without the garbage collection procedure described in the paper, I think.

Volker Stampa
May 02 2017 06:05
@mehdimas @krasserm Sorry, I do not have a concrete timeframe for dynamic replication networks either.
Martin Krasser
May 02 2017 06:10
@mehdimas It would be helpful if you could summarize your specific use cases in RBMHTechnology/eventuate#314. We can then further discuss priorities. Basic uses cases (especially those that don't require replication filters) may be rather easy to support /cc @volkerstampa