If A and B are on the same node (jvm) this doesn't make much sense. If that node crashes and the redelivery is continued by another node (restarted jvm) then the ActorRef to A would be be obsolete.
AtLeastOnceDelivery would be used as a safe hand-off between A and B, but A should not have to wait until msg confirmed by C. Instead, B would reply to A when it has taken over the responsibility of delivering the msg to C. Otherwise AtLeastOnceDelivery adds a lot of overhead (persistent storage) without much value. Then it would be better to implement the retry directly in A without AtLeastOnceDelivery, without persistence. /Patrik > On 1 Sep 2017, at 14:10, Justin du coeur <[email protected]> wrote: > >> On Thu, Aug 31, 2017 at 7:15 PM, Sebastian Oliveri <[email protected]> >> wrote: >> Hi! I am sort of new to Akka. I am implementing DDD around clustered actors. >> Since they are clustered I need to make sure they receive the messages at >> least once. Because of that I have an implicit actor in a Play controller >> which calls my target actor the aggregate passing through a "proxy" Actor >> which implements AtLeastOnceDelivery. So this looks like: A -> B -> C, and C >> replies with an ACK confirm to B. In that precise moment I need to reply to >> A the response so it is the other way around: C -> B -> A. But given the >> context when B received the ACK from C, the sender is B and not A... so I >> kind of handled this by keeping the A actor path in the event messages so I >> can get A actorRef at anytime inside B and reply to the temporary actor >> which fulfills the Ask future in Play controller. Is this a common practice >> to keep an Actor path within the context of Messages to be able to get a >> Sender from a path? > > Actually, it's legal, easier and more common to simply stick A's ActorRef > ("self", rather than the path) into the message. Not only is that a > legitimate pattern, it's going to become the primary way of doing things in > the upcoming Akka Typed. > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: > >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
