In my application I have a service that sends email in response to various user events. There has been an ongoing issue whereby the email sending will fail for some reason so we drop the message and do not attempt to retry it. Included in this failure model is the JVM being shut down. The rules are that duplicate emails should not happen and that failing to send an email is highly undesirable but acceptable. Basically we should be able to retry without fear of duplicates.
Akko-Persistence would appear on the surface to solve the above problem however it seems geared towards storing all messages then replaying a subset of them to recover.
The desired behaviour is that any unprocessed messages (including the message being processed when a failure occurs) are replayed when the actor recovers. In addition if the system is bounced then any pending email are sent.
Is there some section of the Akka documentation I've missed or an easy way to accomplish the above?
For the record we're evaluating Akka 2.4.8 for this : http://doc.akka.io/docs/akka/2.4.8/
Exactly once delivery may be impossible to guarantee, but you can probably be close enough for this kind of use case.
If you get an exception or some kind of callback when sending fails and something that you can see as a certain acknowledgement that it succeeded you can do like this:
Give each mail a unique id and keep a persistent actor state which consists of mails in flight, only send the mail after persisting the fact that you are going to send it, when a mail has been confirmed to be sent, remove it from the in flight.
This will result in two domain events, something like MailSent and MailSendConfirmed, in the event log. After a restart when the actor replay completes you can resend mails that were inflight but not confirmed.
Of course if you want to take everything else that can fail with sending an email, then it will be much harder (send completing but mail bouncing because email address misspelled for example).