Create ReceiveActor implementation of AtLeastOnceDeliveryActor base class

[Aaronontheweb]

It would be really helpful to be able to use typed Receive<T> with the AtLeastOnceDeliveryActor base class within Akka.Persistence - as of right now all we have is the untyped implementation.

[Horusiath]

On the JVM it's realized as trait, which allows for multiple inheritance - at-least-once-delivery semantics can be applied for any kind of actor, either persistent or not.

Since we don't have traits/multi-inheritance in C#, I think that this functionality should be resolved through composition: maybe we should create something like AtLeastOnceDeliverySemantic class that can be used as a regular field and initialized through new AtLeastOnceDeliverySemantic(Context) or even Context.GetAtLeastOnceDeliverySemantic().

[Aaronontheweb]

@Horusiath that's an idea... Have you and @maxim-s discussed this?

[maxim-s]

should I add Receive<T> instead of ReceiveCommand<T> ? I think ReceiveCommand<T> more reasonable for PersistentActorand AtLeastOnceDeliveryActor

[Horusiath]

@maxim-s as AtLeastOnceDeliveryActor is persistent actor, it's methods should reflect persistent actors behavior. Also I've checked the possibilities of decomposing AtLeastOnceDeliverySemantic from actors and these are some of my thoughts:

• This kind of semantic class needs basically only Context. There are two fields from persistent actor that are teoretically required. Usage of both can be opted out.
  • PersistenceId displayed in one of the error logs ⇒ can be replaced with actor Self field
  • IsRecovering is used inside Deliver method ⇒ my proposition is to move this as an optional argument of Deliver method (default: false). In persistent actor we provide custom Deliver method that could call _atLeastOnceDeliverySemantic.Deliver(actor, messageMapping, isRecovering: this.IsRecovering).
• Then all, that's left is to initialize/dispose semantics object in correct actor lifecycle events.

Another enchancement would be moving config fields of AtLeastOnceDelivery into separate settings class - right now associated actor have each field in two versions: default config value and actual, overrideable field value that is used for managing semantics logic. If we could move all of these to separate settings object, we won't need any property overriding. We could apply different settings through new object instead.

[maxim-s]

is it ready?

[maxim-s]

PR #1469