Hi Konrad, Your first suggestion is interesting but I'm not entirely sure I understand it:
The only message the service actor can send is a 'transaction failed' event. I'm currently stopping the faulted transaction actor because the failure is unexpected behaviour (which I am handling gracefully). Are you suggesting I 'resume' the transaction actor on failure, and then forward the 'transaction failed' event to the (possibly corrupt) transaction actor for it to pass to the client? To answer your last question: yes, the code is just that and I wouldn't expect it to fail. However, the supervisor strategy is handling unexpected failures, which we assume can happen anywhere. On Thursday, August 7, 2014 12:29:05 PM UTC+1, Konrad Malawski wrote: > > Hi Lawrence, > In general, exactly one entity in a distributed system should be > responsible for deciding about success / failure, > otherwise there always will be a race of some kind. > > In your case though, the problem arrises because the service actor does > not know if the transaction actor has completed the work, > so how about sending the response back through the transaction actor? > > Also, in your case, can the transaction actor fail after sending it's > response to the client actor, how would that happen (with a NonFatal > exception)? > I'd expect it to do `client ! stuff; context stop self`, is that not the > case? > > > > On Thu, Aug 7, 2014 at 8:59 AM, Lawrence Wagerfield < > [email protected] <javascript:>> wrote: > >> I have problem that involves synchronising outbound messages from a >> parent actor and its child actor. This particular problem is with regards >> to forwarding failure messages to clients. >> >> Here is the example: >> >> I have a service actor that receives a request from a client actor*.* >> >> The service actor creates a new child transaction actor to deal with >> said request, which then response directly to the client actor after >> performing the work. >> >> If the transaction actor fails, it is stopped by the service actor which >> then sends a failure report to the client actor. >> >> The problem is the client actor must now support receiving failures >> after receiving the response it is actually interested in - otherwise the >> potential 'post-workload' failures from the transaction actor may >> deadletter, or worse, be misinterpreted by the client actor (i.e. a >> failure for a subsequent transaction). >> >> I have considered an approach whereby the client actor must wait for the >> transaction >> actor to terminate before safely continuing, since after that point, it >> can be guaranteed that no more messages will be received. >> >> Is there a common solution to this problem? >> >> -- >> >>>>>>>>>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Cheers, > Konrad 'ktoso' Malawski > hAkker @ Typesafe > > <http://typesafe.com> > -- >>>>>>>>>> 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.
