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] <javascript:>>: > > 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] <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. > > > > > *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.
