These are chat archives for RBMHTechnology/eventuate

6th
Jan 2017
Martin Grotzke
@magro
Jan 06 2017 16:29

An idea for the implementation of the EventsourcedProcessor: an event could be processed by the EventsourcedProcessor that runs alongside the EventourcedActor that wrote the event. E.g. given
1) the EventsourcedActor EA1 and EventsourcedProcessor EP1 running in location Loc1,
2) EA2 and EP2 running in Loc2 and
3) EA1 and EA2 writing to the replicated event log L
then EP1 should process all events emitted by EA1 and EP2 should process all events emitted by EA2.

To achieve this AFAICS the EventsourcedProcessor could check if lastEmitterId == sourceId. The (application defined) sourceId would have to be set to the id of the related EventsourcedActor (running in the same location).

The same idea should be applicable to higher level business processes that need to be executed only once per event. In fact I need to think a bit more about the consequences in our use case, but hopefully it should work :-)

So it seems that we have a solution to decide which process(or) shall process a given event. Obviously failover is still not solved and would have to be handled manually if needed, but in our use case this would be fine.

Martin Grotzke
@magro
Jan 06 2017 16:39
This would of course require a stable id of the EventsourcedActor across restarts (i.e. s.th. like self.path.name would not work).
Martin Grotzke
@magro
Jan 06 2017 16:55
Hrm, the emitterId would probably not work with aggregates. Probably using the processId ("the id of the local event log that initially wrote the event") instead would be better.