Hi Marek, If you want to propagate information about failed jobs, or maybe even restart failed jobs, I would go for some type of work pulling pattern where you can keep track of the jobs in progress, who's working on them and who they originated from.
http://letitcrash.com/post/29044669086/balancing-workload-across-nodes-with-akka-2 http://www.michaelpollmeier.com/akka-work-pulling-pattern/ http://blog.goconspire.com/post/64901258135/akka-at-conspire-part-5-the-importance-of-pulling Just adding the original sender to the message won't do you much good, since you can't easily get hold of the message that the failing child was processing in an easy way. B/ On 13 May 2014 at 06:29:06, Marek Kolodziej ([email protected]) wrote: All, I'm dealing with what seems like a simple case, but one that poses some design challenges: There's a local actor system with a client, which reaches out to a remote system that runs the bulk of the business logic.] The remote system will have a fixed IP address, port, etc. - therefore, one can use the context.actorSelection(uri) strategy to get a hold of the ActorRef for the current incarnation of the actor (or a group of routees behind a router). The remote system, being a server, shouldnt be in the business of knowing the location of the client. Given this, it's pretty straightforward to propagate messages from the client to the server, process them, and send a message back to the client. Even if there are several steps, one can propagate the responses through the hierarchy until one reaches the top-level remote actor that the client called, which will know who the sender was on the client side. Let's say on the server side, we have a Master actor that has a router of Worker actors. You can either have the worker respond directly to the client, since the message received from the Client by the Master can be sent to the Worker via the router as "router.tell(message, sender)" instead of "router ! message." However, let's say the Worker throws an exception. If its parent (the Master) is its supervisor and it handles the Workers' failures, the Master can do the usual Restart/Resume/Stop. But let's say that we also want to notify the Client of the failure, e.g. for UI updating purposes. Even if we handle the failure of the Worker via the Master's SupervisorStrategy, we won't know who the original caller was (the Client) that had the processing request payload. If there's one Client and the Client has a host/port/etc. known to the server, then one could use context.actorSelection(uri) to look up the client and send it a message. However, with the server not being in the business of knowing where the Client is coming from (#3), this shouldn't be a requirement. One obvious solution to this is to propagate messages from the Client to the Worker with the Client's ActorRef in the payload, but it seems ugly. Is there a better way? Thanks in advance for your help! Best, Marek -- >>>>>>>>>> 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. -- Björn Antonsson Typesafe – Reactive Apps on the JVM twitter: @bantonsson JOIN US. REGISTER TODAY! Scala Days June 16th-18th, Berlin -- >>>>>>>>>> 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.
