Persist on event may persist events again in case of disaster recovery about eventuate HOT 3 CLOSED

A possible fix for this bug is to use the combination emitter-id and emitter sequence number as delivery id and store this in a dedicated field of a DurableEvent. So in the example above E1 would be emitted by A with this field set to A-1 and a persistOnEvent request by B would use this as delivery id instead of the local sequence number.

from eventuate.

This fix sounds reasonable to me as it uses a unique event identifier and not the non-unique local sequence number for referencing events that caused a PersistOnEvent request.

Instead of using the emitterId it is sufficient to use the processId of the event which is also required for extracting the initial local sequence number (i.e. emitter sequence number) from the vectorTimestamp. An additional method on DurableEvent should be added to generate this identifier (or even replace the existing id method as it is not used within Eventuate).

We still need to make sure to preserve the proper emission order of PersistOnEvent requests which is not given any more by the new identifier. Instead of the current SortedMap[Long, PersistOnEventRequest] we could use a plain Seq[PersistOnEventRequest] but this would increase confirmation complexity from O(log n) to O(n) which is not acceptable.

We therefore need to store the new identifier in addition to the currently used persistOnEventSequenceNr and introduce a second mapping Map[A, PersistOnEventRequest] (which allows us to make a lookup and removal in the current SortedMap[Long, PersistOnEventRequest] via the persistOnEventSequenceNr stored in PersistOnEventRequest) with complexity O(log n).

The new identifier must be stored in a new DurableEvent field named persistOnEventReference: Option[A]. We cannot reuse deliveryId because it would prevent us from using events for ConfirmedDelivery that have been generated via persistOnEvent.

For backwards compatibility we have to deal with the following two situations:

1. confirmation events have set both persistOnEventSequenceNr and persistOnEventReference which allows removal of mapping entries with acceptable complexity i.e O(log n).
2. confirmation events have only set persistOnEventSequenceNr which requires a removal from Map[A, PersistOnEventRequest] with complexity O(n) for a limited number of outstanding PersistOnEvent requests.

from eventuate.

Sounds good to me. A could either be a dedicated type (like case class EventId(processId: String, sequenceNr: Long) or a simple String where processId and sequenceNr are concatenated. The dedicated type might provide better type safety, however the string concatenation pattern is already used in other places in eventuate (e.g. for building a log-id).

from eventuate.