These are chat archives for RBMHTechnology/eventuate

10th
Oct 2016
Volker Stampa
@volkerstampa
Oct 10 2016 06:06
@Tvaroh You see this error because IntelliJ adds the folder for the protobuf generated sources twice to your source folders. Once as target/scala-2.11/src_managed/main and once as target/scala-2.11/src_managed/main/compiled_protobuf. To get rid of these errors you can manually remove target/scala-2.11/src_managed/main in IntelliJ's project settings from the source folders of all modules that contain protobuf files. However one compile error will remain in IntelliJ regarding an already defined object EmbeddedCassandra. Currently you will have to ignore this.
Volker Stampa
@volkerstampa
Oct 10 2016 06:19

@e-Evolution Maybe a quote from the Eventuate documentation answers your question:

Eventuate is not a complete (micro-)service development framework. It focuses more on event-sourcing building blocks and the reliable and causally consistent communication infrastructure between event-sourced services. It leaves service deployment and accessibility an application-level concern. Later versions of Eventuate may extend into these directions though.

Alexander Semenov
@Tvaroh
Oct 10 2016 06:47
Thanks Volker
Martin Krasser
@krasserm
Oct 10 2016 07:01

@e-Evolution Eventuate supports the development of event-driven and event-sourced micro-services but is not a complete service development framework (yet). See also footnote 1 on the Eventuate Introduction page.

When comparing to Lagom, it makes most sense to compare it with the persistence part of Lagom. Lagom persistence is based on Akka Persistence and you can find a (rather old) comparison here.

On a very high level, event persistence in Akka Persistence is based on a total order of events, which requires application to choose CP of CAP (on the command side). Eventuate supports the same persistence model but additionally support causal event ordering in a replicated event log. This enables applications to choose AP of CAP so that they remain available for writes during networks partitions. More in Architecture.

Persistent entities in Akka Persistence are restricted to be singletons, wheres persistent entities in Eventuate can be replicated (up to global scale e.g. in different data centers) and each replica remains available for writes during network partitions. Consistency across replica state is causal consistency which is the strongest consistency that is still compatible with AP of CAP.

In Eventuate, causality is also preserved for event-based service interactions: event streams consumed by Eventuate services are guaranteed to be causally ordered i.e. a Eventuate service will never see an effect before its cause. Furthermore, Eventuate services can rely on event streams that do not contain duplicates. Causal ordering and de-duplicated event streams can dramatically simplify service logic. Causal ordering is also preserved in Eventuate when aggregating events from (potentially globally) distributed services on the query side of a CQRS application. AFAIK, you cannot have these guarantees for Lagom based applications.

Anyway, I don’t see a fundamental problem supporting Eventuate’s persistence model in Lagom which would allow Lagom services to be replicated across data centers with causal consistency of service state.

Hope that helps!

Alexander Semenov
@Tvaroh
Oct 10 2016 14:52

@krasserm I'm considering the case when same node is added concurrently to a tree. There are several ways to handle it in the paper and one of them probably suites us nicely, namely leave the node with higher vector timestamp. So, when I detect this situation, I look up Versioned[Edge[A, Id]] from the underlying ORSet's versionedEntries (by iteration unfortunately) and then decide what exactly duplicate node to remove by comparing their vectorTimestamps (one is taken from the "versioned", another comes from CRDTServiceOps.update method "event" argument.

Does it make sense?

Martin Krasser
@krasserm
Oct 10 2016 16:17
@Tvaroh No, this doesn't make sense. Vector timestamps have a partial order and the timestamps of concurrent updates are not ordered i.e. both t1 < t2 and t2 < t1 evaluate to false and only t1 conc t2 or t2 conc t1 evaluate to true.
Alexander Semenov
@Tvaroh
Oct 10 2016 16:48
Martin, okay, alternative approach (from the paper) is to take the first node of two from the breadth-first traversal. But that requires the tree to be ordered.
and I can't see other ways for non-ordered tree
if we have a conflicting node c under root->a and root->b, there should be a traversal order for root's children a and b. Will look into implementing ordered tree cause that's what I need anyway
Martin Krasser
@krasserm
Oct 10 2016 17:00
This message was deleted
Martin Krasser
@krasserm
Oct 10 2016 17:15

and I can't see other ways for non-ordered tree

you could also use system timestamps and/or emitter ids for automated conflict resolution. But I still didn't read the paper and remain curious for (better) alternatives ;-)

Will look into implementing ordered tree

Which node ordering criteria are used in the paper?

Martin Krasser
@krasserm
Oct 10 2016 17:26

and I can't see other ways for non-ordered tree

you could also require the node id type A to be an instance of the Ordering[A] type class (i.e. type parameter A must have an Ordering context bound)

Alexander Semenov
@Tvaroh
Oct 10 2016 17:26

It proposes to have Unique Position Identifiers along with nodes. I'm still reading about it though:

A tree with UPI associated to nodes can be built using any sequential editing UPIs. However the WOOT and RGA UPI requires tombstones and thus are more adapted to a 2P CvRDT that contains these tombstones. For 2P CmRDT, the Logoot or Treedoc UPI approaches are more suitable. The complexity of the children order computation depends on the approach used. An example of such construct is [6].

yes, Ordering is fine though it might be a limitation for the payload
Martin Krasser
@krasserm
Oct 10 2016 17:28
No Ordering context bound for the payload type, only for the id type
Alexander Semenov
@Tvaroh
Oct 10 2016 17:29
that sounds reasonable :+1: And it's a better starting point then diving into ordered trees
wait, but ids are the same for duplicated nodes, only parent ids differ
Martin Krasser
@krasserm
Oct 10 2016 17:31

wait, but ids are the same for duplicated nodes, only parent ids differ

yeah, and the addition to the parent node with the lower (or higher) id wins :smiley:

And it's a better starting point then diving into ordered trees

really?

Alexander Semenov
@Tvaroh
Oct 10 2016 17:32
I mean it's easier to implement and have something working
regarding parent id - :+1:
Martin Krasser
@krasserm
Oct 10 2016 17:32

I mean it's easier to implement and have something working

I agree :smiley:

Alexander Semenov
@Tvaroh
Oct 10 2016 17:35
thanks for the suggestions
Martin Krasser
@krasserm
Oct 10 2016 17:36
you're welcome