Hi Andrey, first off, I understand your desire, I think it might make sense for your particular application. For the Akka toolkit on the other hand, things are a bit more complicated: this feature would have to come with the caveat that it sometimes works and sometimes not, because actor shutdown can proceed really like “pulling the plug”, especially in the cluster case. While that is completely okay for you usage, we don’t add features that only work sometimes (we still have a few left which are deprecated and will be removed in 2.4). It might (!) be appropriate to signal the cause of immediate termination in a way that it specific to your application, in a shared volatile variable that is read by those actors that are interested in it (preferably in a non-static location, i.e. passing around an object which contains it to all affected actors).
Regards, Roland 29 mar 2014 kl. 17:50 skrev Andrey <[email protected]>: > Thank you Roland, > > Just to summarize the use case I have in mind: an actor fails and the outcome > gets decided by the supervision policy; if the decision is to stop I'd like > the entire hierarchy to be terminated and the cause of the termination to be > available to all actors of the hierarchy in the postStop() hook. This is very > similar to the initial (stopping) phase of Restart supervision which makes a > preRestart() call on the old instance of the actor. > > The correctness of the application doesn't rely on the execution of the hook, > but it makes it easier to implement "best effort" shutdown logic. > > I was just hoping to be able to piggyback on the "out-of-bound" delivery > property of the system messages. Since each individual actor in a hierarchy > may have an arbitrary long message queue, relying on a user message or the > watch will not have the same effect of immediacy as is the case with shutdown > due to supervision. The only thing that's missing is the context (the > exception that caused the termination). Akka has it, all that's left is to > make it available to the postStop() hook. > > Regards > Andrey > > On Saturday, March 29, 2014 12:29:56 AM UTC-7, rkuhn wrote: > Hi Andrey, > > the supervision mechanism (where I include the ability to stop for now) is a > low-level facility for managing the lifecycle of those objects whose job it > is to model your domain. Stopping an actor that way is the same as unplugging > the power to your server: it will not gracefully shut down, it just stops > functioning. Properly shutting down the server is done entirely differently: > you ask it nicely (i.e. send a message) and it will do whatever is necessary > to come to an orderly halt. > > So, reacting with business-level actions should be reserved to business-level > messages. Lifecycle hooks are just for plumbing (i.e. > registering/unregistering from system services). You should be aware that > your actor can always cease to exist without any hooks being called—when the > power gets cut. As long as the actor system is running, it is important that > the hooks function, but when it isn’t then you must not depend on them for > the correctness of your distributed application. > > This means that all lifecycle changes you control should be done using normal > user messages. As a rule of thumb, the only argument you ever pass to > context.stop() is `self`, with the possible exception of stopping direct > child actors. Terminating in response to a sibling’s failure can occur in two > modes: if the error condition is fatal and not isolated between the siblings > (i.e. they share something which fails for all of them simultaneously) then > they must all abort in the power-cut sense, e.g. by applying an > AllForOneStrategy; if the error condition is handled, then use a > OneForOneStrategy, have the parent watch the children and send appropriate > requests or notifications to siblings when receiving a Terminated message for > one of them. > > Regards, > > Roland > > 28 mar 2014 kl. 23:03 skrev Andrey <[email protected]>: > >> Hello, >> >> In my actor's code, I'd like to know the reason why the postStop() hook is >> called. In particular I'm interested in knowing whether the actor is being >> terminated due to the supervision process (because one of the siblings has >> failed -- in which case an instance of the original exception would be >> fantastic!), or as result of somebody intentionally stopping it via a call >> to the ActorContext.stop() on the self, or parent, or parent of parent... or >> ActorSystem.stop() method. >> >> In case of the former the actor might choose to perform certain actions like >> a transaction rollback, sending a NACK to a network connection, trigger a >> compensation process, and stuff like that, whereas the latter would result >> in a commit, or an ACK, or success message in the log file, or whatever else >> the actors normally do in the postStop(). >> >> I'm wondering how can I implement something like that? Or, what's the >> alternative? >> >> Thanks >> Andrey >> >> PS. In general, I think it would sometimes be useful to able to pass along >> with a stop() call some additional context for use in the postStop() hook of >> the Actors being stopped. postStop() could take an Optional parameter >> similar to how preRestart() does it. >> >> >> -- >> >>>>>>>>>> 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. > > > > Dr. Roland Kuhn > Akka Tech Lead > Typesafe – Reactive apps on the JVM. > twitter: @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. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @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.
