Hi John, keeping the per-message state in a Future transformation is the right thing to do in this case, your mapping code example is correct. Another alternative would be to have the “parent” create another child Actor per request that is responsible for the retries.
Regards, Roland > 29 sep 2015 kl. 22:26 skrev John Ulric <[email protected]>: > > @Ryan, thanks. But as I see it, wrapping is essential here. > > Please allow me to explain what I'm trying to do. Maybe I'm completely > mistaken and there's a much better way to do it: > > There are three parties (code components), I'll name them caller, parent and > child. The caller (actor or non-actor, doesn't matter) essentially wants to > send a message to the child actor and has a fixed contract with that child > actor. Part of that contract is that the child actor responds to each message > with either a Status.Success or Status.Failure. For each message, the child > actor performs an action that is prone to failure. So there is an > intermediate parent actor that relays messages between the caller and the > child actor. The job of the parent actor is to do some bookkeeping of which > messages failed and how often an when and to organize a controlled retry > procedure like backoff, circuit breaker, whatever plus monitoring. > > That parent actor is intended to be generic, knowing nothing of the message > contents between the caller and the child. So if I used just "tell" without a > way to wrap the failed message with the retry status, there's no way I see > for the parent actor to keep track of the retry status of each of the relayed > messages. Except either modifying the child contract to recognize a wrapped > message (not possible here) or keep persistent state in the parent actor for > each relayed message (seems very unpretty to me). > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/> > >>>>>>>>>> Check the FAQ: > >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > >>>>>>>>>> <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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at http://groups.google.com/group/akka-user > <http://groups.google.com/group/akka-user>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. Dr. Roland Kuhn Akka Tech Lead Typesafe <http://typesafe.com/> – Reactive apps on the JVM. twitter: @rolandkuhn <http://twitter.com/#!/rolandkuhn> -- >>>>>>>>>> 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
