0

So for eg: I have actor X and Y.

Actor X persists message to journal, then it sends message to Y. Y receives message, and sends confirmation back to X to let it know have received message. When X receives this confirmation, I want it to a) delete the message from the journal so the message isn't replayed on recovery. (this part doesn't seem to be possible). b) "Mark" the message as completed (delivered). This part I think will be done with either the Log (using the log on recovery), or through adding "tags" to journal (through event adapter, but I am not sure if that's possible will update if its a viable option).

This makes me realize, how does akka persistence actually work. If a actor is persisting all messages, and then the actor fails and needs to recover, will it not recover all these messages regardless of delivery? I know it is to maintain state (so for fsm I get it), but if I have a supervisor actor that persists messages to then pass on to workers, surely I would want to be able to change this journals entries so that I wont recover (and then resend) messages that have already been processed? (so thats why I am asking, I am obviously missing something)

user3038404
  • 331
  • 5
  • 14

1 Answers1

1

Akka persistence implements eventsourcing which in general isn't a perfect fit for a queue (that does not mean it is impossible to do).

For an event sourced work manager you would record an event with the fact that the workload is sent out to a worker, which is then applied to the state of the actor, for example a list of work in progress, then send the actual work. When a workload is done you record that fact, removing the in progress item from the state, so that if the work manager restarts it could get in contact with the worker to see if the work is still in progress or retrigger it with some other worker etc.

The distributed workers sample doesn't cover the redelivery part AFAIR but could be a good source of inspiration.

With the new typed EventSourcedBehavior you can delaratively enable snapshotting and event deletion https://doc.akka.io/docs/akka/current/typed/persistence-snapshot.html#event-deletion while with the classic PersistentActor there is a more imperative deleteMessages https://doc.akka.io/docs/akka/current/persistence.html#message-deletion

For classic actors there is At-Least-Once-Delivery built on top of persistence, and for the new APIs we have work in progress for something called Reliable Delivery which will allow for a greater degree of choosing what level of reliability you are after.

Note that it depends on the journal you use if and how fast the events are actually deleted or just marked as removed, so you'll have to look into the details there as well.

johanandren
  • 11,249
  • 1
  • 25
  • 30