Linking actors and trapping exit in akka 1.1.2

[Chris Marshall]

I've been using scala actors for quite a while now and am struggling a bit with how to link my actors in such a way that an actor cannot die for some unexpected reason without some part of my program being informed (I've looked here: http://jonasboner.com/2010/01/04/introducing-akka.html). 

My understanding of linking in Akka is that it enables you to say "I can restart my actor in these exceptional situations" by providing a fault handler on that actor's supervisor. But what about the case that some other exception has occurred which is not recoverable at all (it might indicate a bug in the program serious enough for me to want to react to it and shut down).

Taken from Actor scaladoc (http://akka.io/api/akka/1.1.2/#akka.actor.Actor):

"The Actor's API is available in the 'self' member variable ... Here you also find fields like ... trapExit"

Really? Am I being an idiot? I can't find trapExit in ActorRef.

Taken from the ActorRef.link scaladoc:

"Links an other actor to this actor. Links are unidirectional and means that a the linking actor will receive a notification if the linked actor has crashed.

If the 'trapExit' member field of the 'faultHandler' has been set to at contain at least one exception class then it will 'trap' these exceptions and automatically restart the linked actors according to the restart strategy defined by the 'faultHandler'."

I try a little experiment to see what happens if I link two actors and cause one of them to die:

    class Worker extends Actor {

      protected def receive = {

        case s : Symbol => sys.error("AAIIIE! " + s + " from actor " + System.identityHashCode(this))

        case p => println(p + " from " + System.identityHashCode(this))

      }

    }

    class Supervisor extends Actor {

      self.faultHandler = akka.config.Supervision.OneForOneStrategy(List(classOf[java.io.IOException]), 5, 1000)

      protected def receive = {

        case p => println("Super " + p) ;

      }

    }

    import Actor._

    val s = actorOf[Supervisor]

    s.start()

    val w = actorOf(new Worker)

    w.start()

    s link w //I'll swap these

    w ! "Hello"

    w ! 'foo

    w ! 3.4

This prints:

Hello from 381531395

[ERROR]   [22/06/11 15:59] [akka:event-driven:dispatcher:global-1] [LocalActorRef] 'foo

java.lang.RuntimeException: AAIIIE! 'foo from actor 381531395

at scala.sys.package$.error(package.scala:27)

So it doesn't look like any message has been passed to the supervisor, although it's clear that the exception has killed the worker. However, when I swap "s link w" to "w link s" I get this:

Hello from 381531395

3.4 from 381531395

[ERROR]   [22/06/11 16:00] [akka:event-driven:dispatcher:global-1] [LocalActorRef] 'foo

java.lang.RuntimeException: AAIIIE! 'foo from actor 381531395

at scala.sys.package$.error(package.scala:27)

So it looks like in this case, the worker has been restarted (although the supervisor has not received anything, again) - but it is the same underlying "Worker" instance. My third change was to switch back to "s link w" but specify that I want to restart on any exception:

Hello from 1729747990

3.4 from 591786211

[ERROR]   [22/06/11 16:02] [akka:event-driven:dispatcher:global-1] [LocalActorRef] 'foo

java.lang.RuntimeException: AAIIIE! 'foo from actor 1729747990

at scala.sys.package$.error(package.scala:27)

So in this instance, it seems as though akka has indeed restarted my actor (with a new instance of the Worker)

Any help here?

• How can I get *some* callback for an actor exiting with an unexpected exception? (is "postStop" the only mechanism?)
• Why if I switch round "supervisor link worker" to "worker link supervisor" does the worker not die on throwing an Exception?

Chris

[Peter Vlugter]

Hi Chris,

> This prints:
>
> Hello from 381531395
> [ERROR] [22/06/11 15:59] [akka:event-driven:dispatcher:global-1] [LocalActorRef] 'foo
> java.lang.RuntimeException: AAIIIE! 'foo from actor 381531395
> at scala.sys.package$.error(package.scala:27)
>
> So it doesn't look like any message has been passed to the supervisor, although it's clear that the exception has killed the worker.

A message is sent to the supervisor but it is handled automatically.

From the docs:

"If a linked Actor is failing and throws an exception then an “Exit(deadActor, cause)’ message will be sent to the supervisor (however you should never try to catch this message in your own message handler, it is managed by the runtime)."

http://akka.io/docs/akka/1.1.2/scala/fault-tolerance.html#the-supervising-actor-s-side-of-things

The receiving of this message is here:

https://github.com/jboner/akka/blob/v1.1.2/akka-actor/src/main/scala/akka/actor/Actor.scala#L484

And the logic of what to do is here:

https://github.com/jboner/akka/blob/v1.1.2/akka-actor/src/main/scala/akka/actor/ActorRef.scala#L880

Since the exception is not covered and there is no supervisor (of the supervisor) to pass up to, the actor is simply stopped.

> However, when I swap "s link w" to "w link s" I get this:
>
> Hello from 381531395
> 3.4 from 381531395
> [ERROR] [22/06/11 16:00] [akka:event-driven:dispatcher:global-1] [LocalActorRef] 'foo
> java.lang.RuntimeException: AAIIIE! 'foo from actor 381531395
> at scala.sys.package$.error(package.scala:27)
>
> So it looks like in this case, the worker has been restarted (although the supervisor has not received anything, again) - but it is the same underlying "Worker" instance.

In this case the worker doesn't have a supervisor so the lifecycle of the actor is considered. The default is permanent and so it simply resumes (the same instance of the actor and the exception is just logged).

See here:

https://github.com/jboner/akka/blob/v1.1.2/akka-actor/src/main/scala/akka/actor/ActorRef.scala#L1035

> My third change was to switch back to "s link w" but specify that I want to restart on any exception:
>
> Hello from 1729747990
> 3.4 from 591786211
> [ERROR] [22/06/11 16:02] [akka:event-driven:dispatcher:global-1] [LocalActorRef] 'foo
> java.lang.RuntimeException: AAIIIE! 'foo from actor 1729747990
>
> at scala.sys.package$.error(package.scala:27)
>
> So in this instance, it seems as though akka has indeed restarted my actor (with a new instance of the Worker)

Yes, this time it's restarted by the supervisor.

>
> Any help here?
> • How can I get *some* callback for an actor exiting with an unexpected exception? (is "postStop" the only mechanism?)

The supervisor hierarchy approach is to have the unexpected exception go to the supervisor's supervisor, and so on up the hierarchy, until it can be handled.

> • Why if I switch round "supervisor link worker" to "worker link supervisor" does the worker not die on throwing an Exception?

It's determined by the lifecycle of the actor in this case.

Hope that helps,

Peter

[Garry]

Does it go through the supervisor's pre/postRestart(Throwable) methods
when the linked dead actor terminates? Does a temporary actor go
through preRestart of the supervisor?

If it doesn't go through the supervisor (i.e. one can't intercept the
Exit message) and it doesn't call preRestart() of the supervisor, I am
not sure what good it does to have a supervisor? If the previous is
true then all a supervisor decides is if it is temporary don't restart
it, otherwise it should enforce this policy
OneForOneStrategy(List(classOf[java.io.IOException] ),
5, 1000). Please correct me if I am wrong, but it seems like the
supervisor should get lifeCycle events of the actors it is
supervising.

If it were a human supervisor, I would say it has a pretty easy job,
because it doesn't have to manage their people. ;)

On Jun 22, 11:41 pm, Peter Vlugter <pvlug...@gmail.com> wrote:
> Hi Chris,
>
> > This prints:
>
> > Hello from 381531395
> > [ERROR]   [22/06/11 15:59] [akka:event-driven:dispatcher:global-1] [LocalActorRef] 'foo
> > java.lang.RuntimeException: AAIIIE! 'foo from actor 381531395
> >    at scala.sys.package$.error(package.scala:27)
>
> > So it doesn't look like any message has been passed to the supervisor, although it's clear that the exception has killed the worker.
>
> A message is sent to the supervisor but it is handled automatically.
>
> From the docs:
>
> "If a linked Actor is failing and throws an exception then an “Exit(deadActor, cause)’ message will be sent to the supervisor (however you should never try to catch this message in your own message handler, it is managed by the runtime)."
>

> http://akka.io/docs/akka/1.1.2/scala/fault-tolerance.html#the-supervi...

>
> The receiving of this message is here:
>

> https://github.com/jboner/akka/blob/v1.1.2/akka-actor/src/main/scala/...

>
> And the logic of what to do is here:
>

> https://github.com/jboner/akka/blob/v1.1.2/akka-actor/src/main/scala/...

>
> Since the exception is not covered and there is no supervisor (of the supervisor) to pass up to, the actor is simply stopped.
>
> > However, when I swap "s link w" to "w link s" I get this:
>
> > Hello from 381531395
> > 3.4 from 381531395
> > [ERROR]   [22/06/11 16:00] [akka:event-driven:dispatcher:global-1] [LocalActorRef] 'foo
> > java.lang.RuntimeException: AAIIIE! 'foo from actor 381531395
> >    at scala.sys.package$.error(package.scala:27)
>
> > So it looks like in this case, the worker has been restarted (although the supervisor has not received anything, again) - but it is the same underlying "Worker" instance.
>
> In this case the worker doesn't have a supervisor so the lifecycle of the actor is considered. The default is permanent and so it simply resumes (the same instance of the actor and the exception is just logged).
>
> See here:
>

> https://github.com/jboner/akka/blob/v1.1.2/akka-actor/src/main/scala/...

[oxbow_lakes]

Thanks Peter - this makes sense. Except for one further question! I

f the "Exit" message callbacks are passed up the supervisor hierarchy
but *I* am not supposed to handle them, I'm still confused about how/
where to put a hook in my program where I would call this method:

def kaboom(msg : Any) = { println("unexpected actor exit " + msg);
sys.exit(-1) }

On Jun 23, 4:41 am, Peter Vlugter <pvlug...@gmail.com> wrote:
> Hi Chris,
>

[Jonas Bonér]

On 23 June 2011 09:03, oxbow_lakes <oxbow...@gmail.com> wrote:

Thanks Peter - this makes sense. Except for one further question! I

f the "Exit" message callbacks are passed up the supervisor hierarchy
but *I* am not supposed to handle them, I'm still confused about how/
where to put a hook in my program where I would call this method:

   def kaboom(msg : Any) = { println("unexpected actor exit " + msg);
sys.exit(-1) }

In the preRestart or postRestart hooks.

 

On Jun 23, 4:41 am, Peter Vlugter <pvlug...@gmail.com> wrote:
> Hi Chris,
>

> It's determined by the lifecycle of the actor in this case.
>
> Hope that helps,
>
> Peter

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--

Jonas Bonér
CTO 

Typesafe - Enterprise-Grade Scala from the Experts

Phone: +46 733 777 123

Twitter: @jboner

[Garry]

I rewrote (see below) the initial code to include the lifecycle
hooks. However, it appears that they are not getting called. See
this log.

[INFO] [6/23/11 10:04 AM] [qtp16579154-44] [Supervisor] preStart of
supervisor com.dynafocus.apns.stats.Supervisor
[INFO] [6/23/11 10:04 AM] [qtp16579154-44] [Worker] preStart of
worker com.dynafocus.apns.stats.Worker
[INFO] [6/23/11 10:04 AM] [akka:event-driven:dispatcher:global-4]
[Worker] Hello from com.dynafocus.apns.stats.Worker
[ERROR] [6/23/11 10:04 AM] [akka:event-driven:dispatcher:global-4]

[LocalActorRef] 'foo
java.lang.RuntimeException: AAIIIE! 'foo from actor

com.dynafocus.apns.stats.Worker
at scala.sys.package$.error(package.scala:27)
at com.dynafocus.apns.stats.Worker$$anonfun$receive
$1.apply(Supervisor.scala:25)
at com.dynafocus.apns.stats.Worker$$anonfun$receive
$1.apply(Supervisor.scala:24)
at akka.actor.Actor$class.apply(Actor.scala:476)
at com.dynafocus.apns.stats.Worker.apply(Supervisor.scala:7)
at akka.actor.LocalActorRef.invoke(ActorRef.scala:861)
at akka.dispatch.MessageInvocation.invoke(MessageHandling.scala:26)
at akka.dispatch.ExecutableMailbox
$class.processMailbox(ExecutorBasedEventDrivenDispatcher.scala:209)
at akka.dispatch.ExecutorBasedEventDrivenDispatcher$$anon
$4.processMailbox(ExecutorBasedEventDrivenDispatcher.scala:120)
at akka.dispatch.ExecutableMailbox
$class.run(ExecutorBasedEventDrivenDispatcher.scala:182)
at akka.dispatch.ExecutorBasedEventDrivenDispatcher$$anon
$4.run(ExecutorBasedEventDrivenDispatcher.scala:120)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
at akka.dispatch.MonitorableThread.run(ThreadPoolBuilder.scala:182)

[INFO] [6/23/11 10:04 AM] [akka:event-driven:dispatcher:global-4]
[Worker] 3.4 from com.dynafocus.apns.stats.Worker


package com.dynafocus.apns.stats

import akka.actor._
import akka.config._
import akka.event._

class Worker extends Actor {
override def preStart(): Unit = {
EventHandler.info(this, "preStart of worker " + self.id)
}

override def postStop() = {
EventHandler.info(this, "postStop of worker " + self.id)
}

override def preRestart(err:Throwable) = {
EventHandler.info(this, "preRestart of worker " + self.id)
}

override def postRestart(err:Throwable) = {
EventHandler.info(this, "postRestart of worker " + self.id)

}

protected def receive = {
case s: Symbol => sys.error("AAIIIE! " + s + " from actor " +

self.id)
case p => EventHandler.info(this, p + " from " + self.id)

}
}

class Supervisor extends Actor {
self.faultHandler =

Supervision.OneForOneStrategy(List(classOf[Exception]), 5, 1000)

override def preStart(): Unit = {
EventHandler.info(this, "preStart of supervisor " + self.id)
}

override def postStop() = {
EventHandler.info(this, "postStop of supervisor " + self.id)
}

override def preRestart(err:Throwable) = {
EventHandler.info(this, "preRestart of supervisor " + self.id)
}

override def postRestart(err:Throwable) = {
EventHandler.info(this, "postRestart of supervisor " + self.id)
}

protected def receive = {
case p => EventHandler.info(this, "Super " + p + " " + self.id);
}
}

object Test {

def test() = {
import Actor._
val s = actorOf[Supervisor].start
val w = actorOf[Worker].start
w link s

w ! "Hello"
w ! 'foo
w ! 3.4
}
}

On Jun 23, 8:25 am, Jonas Bonér <jo...@jonasboner.com> wrote:

> On 23 June 2011 09:03, oxbow_lakes <oxbowla...@gmail.com> wrote:
>
> > Thanks Peter - this makes sense. Except for one further question! I
>
> > f the "Exit" message callbacks are passed up the supervisor hierarchy
> > but *I* am not supposed to handle them, I'm still confused about how/
> > where to put a hook in my program where I would call this method:
>
> >    def kaboom(msg : Any) = { println("unexpected actor exit " + msg);
> > sys.exit(-1) }
>
> In the preRestart or postRestart hooks.
>
>
>
>
>
>
>
>
>
>
>
> > On Jun 23, 4:41 am, Peter Vlugter <pvlug...@gmail.com> wrote:
> > > Hi Chris,
>
> > > It's determined by the lifecycle of the actor in this case.
>
> > > Hope that helps,
>
> > > Peter
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Akka User List" group.
> > To post to this group, send email to akka...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > akka-user+...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/akka-user?hl=en.
>
> --
> Jonas Bonér
> CTO

> Typesafe <http://www.typesafe.com/> - Enterprise-Grade Scala from the

> Experts
> Phone: +46 733 777 123

> Twitter: @jboner <http://twitter.com/jboner>

[Jonas Bonér]

Try doing 's link w' 

-- 

Jonas Bonér

CTO 

Typesafe - Enterprise-Grade Scala from the Experts

Phone: +46 733 777 123

Twitter: @jboner

[Garry]

Ok that fixed it so that it called the worker's lifecycle messages.
However, it appears that the Supervisor still isn't notified. I
believe that one of the earlier e-mails said that one was not supposed
to capture the Exit message. Is that correct? If so, it would be
nice to have the ability to have additional methods on the supervisor
called:

// this one would be called on the supervisor after the dead actor's
preRestart
def onLinkedActorDeath(deadActor:ActorRef, error:Throwable) : Unit

// this one would be called on the supervisor after the new actor's
postRestart invocation
def onLinkedActorRestart(newActor:ActorRef) : Unit

[INFO] [6/23/11 10:41 AM] [qtp16579154-25] [Supervisor] preStart of
supervisor com.dynafocus.apns.stats.Supervisor
[INFO] [6/23/11 10:41 AM] [qtp16579154-25] [Worker] preStart of
worker com.dynafocus.apns.stats.Worker
[INFO] [6/23/11 10:41 AM] [akka:event-driven:dispatcher:global-4]
[Worker] Hello from com.dynafocus.apns.stats.Worker
[ERROR] [6/23/11 10:41 AM] [akka:event-driven:dispatcher:global-4]

[LocalActorRef] 'foo
java.lang.RuntimeException: AAIIIE! 'foo from actor
com.dynafocus.apns.stats.Worker
at scala.sys.package$.error(package.scala:27)

... snip

[INFO] [6/23/11 10:41 AM] [akka:event-driven:dispatcher:global-7]
[Worker] preRestart of worker com.dynafocus.apns.stats.Worker
[INFO] [6/23/11 10:41 AM] [akka:event-driven:dispatcher:global-7]

[Worker] preStart of worker com.dynafocus.apns.stats.Worker

[INFO] [6/23/11 10:41 AM] [akka:event-driven:dispatcher:global-7]
[Worker] postRestart of worker com.dynafocus.apns.stats.Worker
[INFO] [6/23/11 10:41 AM] [akka:event-driven:dispatcher:global-10]
[Worker] 3.4 from com.dynafocus.apns.stats.Worker

One last question is if the supervisor itself dies, is it supposed to
restart automatically?

Thanks for helping clarify things with these supervisors.
Garry

On Jun 23, 10:28 am, Jonas Bonér <jo...@jonasboner.com> wrote:
> Try doing 's link w'
>
> --
> Jonas BonérCTO

> Typesafe (http://www.typesafe.com/) - Enterprise-Grade Scala from the Experts

> Phone: +46 733 777 123

> Twitter: @jboner (http://twitter.com/jboner)

> > EventHandler.info (http://EventHandler.info)(this, "preStart of worker " + self.id)
> >  }
>
> >  override def postStop() = {
> > EventHandler.info (http://EventHandler.info)(this, "postStop of worker " + self.id)

> >  }
>
> >  override def preRestart(err:Throwable) = {

> > EventHandler.info (http://EventHandler.info)(this, "preRestart of worker " + self.id)

> >  }
>
> >  override def postRestart(err:Throwable) = {

> > EventHandler.info (http://EventHandler.info)(this, "postRestart of worker " + self.id)

> >  }
>
> >  protected def receive = {
> >  case s: Symbol => sys.error("AAIIIE! " + s + " from actor " +
> > self.id)

> >  case p => EventHandler.info (http://EventHandler.info)(this, p + " from " + self.id)

> >  }
> > }
>
> > class Supervisor extends Actor {
> >  self.faultHandler =
> > Supervision.OneForOneStrategy(List(classOf[Exception]), 5, 1000)
>
> >  override def preStart(): Unit = {

> > EventHandler.info (http://EventHandler.info)(this, "preStart of supervisor " + self.id)
> >  }
>
> >  override def postStop() = {
> > EventHandler.info (http://EventHandler.info)(this, "postStop of supervisor " + self.id)

> >  }
>
> >  override def preRestart(err:Throwable) = {

> > EventHandler.info (http://EventHandler.info)(this, "preRestart of supervisor " + self.id)

> >  }
>
> >  override def postRestart(err:Throwable) = {

> > EventHandler.info (http://EventHandler.info)(this, "postRestart of supervisor " + self.id)
> >  }
>
> >  protected def receive = {
> >  case p => EventHandler.info (http://EventHandler.info)(this, "Super " + p + " " + self.id);

> >  }
> > }
>
> > object Test {
>
> >  def test() = {
> >  import Actor._
> >  val s = actorOf[Supervisor].start
> >  val w = actorOf[Worker].start
> >  w link s
> >  w ! "Hello"
> >  w ! 'foo
> >  w ! 3.4
> >  }
> > }
>

> > On Jun 23, 8:25 am, Jonas Bonér <jo...@jonasboner.com (http://jonasboner.com)> wrote:

> > > On 23 June 2011 09:03, oxbow_lakes <oxbowla...@gmail.com (http://gmail.com)> wrote:
>
> > > > Thanks Peter - this makes sense. Except for one further question! I
>
> > > > f the "Exit" message callbacks are passed up the supervisor hierarchy
> > > > but *I* am not supposed to handle them, I'm still confused about how/
> > > > where to put a hook in my program where I would call this method:
>
> > > > def kaboom(msg : Any) = { println("unexpected actor exit " + msg);
> > > > sys.exit(-1) }
>
> > > In the preRestart or postRestart hooks.
>

> > > > On Jun 23, 4:41 am, Peter Vlugter <pvlug...@gmail.com (http://gmail.com)> wrote:
> > > > > Hi Chris,
>
> > > > > It's determined by the lifecycle of the actor in this case.
>
> > > > > Hope that helps,
>
> > > > > Peter
>
> > > > --
> > > > You received this message because you are subscribed to the Google Groups
> > > > "Akka User List" group.

> > > > To post to this group, send email to akka...@googlegroups.com (mailto:akka...@googlegroups.com).

> > > > To unsubscribe from this group, send email to

> > > > akka-user+...@googlegroups.com (mailto:akka-user+...@googlegroups.com).

> > > > For more options, visit this group at
> > > >http://groups.google.com/group/akka-user?hl=en.
>
> > > --
> > > Jonas Bonér
> > > CTO
> > > Typesafe <http://www.typesafe.com/> - Enterprise-Grade Scala from the
> > > Experts
> > > Phone: +46 733 777 123
> > > Twitter: @jboner <http://twitter.com/jboner>
>
> > --
> > You received this message because you are subscribed to the Google Groups "Akka User List" group.

> > To post to this group, send email to akka...@googlegroups.com (mailto:akka...@googlegroups.com).
> > To unsubscribe from this group, send email to akka-user+...@googlegroups.com (mailto:akka-user+...@googlegroups.com).

[Jonas Bonér]

 Thursday, June 23, 2011 at 4:56 PM, Garry wrote:

Ok that fixed it so that it called the worker's lifecycle messages.

Good. 

However, it appears that the Supervisor still isn't notified. I

If the callbacks are invoked then the supervisor is notified since it is the supervisor that invokes them.  

believe that one of the earlier e-mails said that one was not supposed
to capture the Exit message. Is that correct? If so, it would be

That is wrong. It is all automatic. You shouldn't do anything apart from the declarative configuration of them. 

Exit is an internal message, should not be messed with. 

Why do you want to interfere with the supervisor management? It is against the whole idea.  

nice to have the ability to have additional methods on the supervisor
called:

// this one would be called on the supervisor after the dead actor's
preRestart
def onLinkedActorDeath(deadActor:ActorRef, error:Throwable) : Unit

// this one would be called on the supervisor after the new actor's
postRestart invocation
def onLinkedActorRestart(newActor:ActorRef) : Unit

That would be wrong. It is the child actors responsibility to clean up and re-init.  

To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.

[Garry]

Q: Why do you want to interfere with the supervisor management? It is
against the whole idea.

I have a hierarchy of actors that act like a router down the tree. So
if one dies I need to know which one replaced it so I can remove/add
it back to my list so I can send new messages to it.

Do I just need to write my own custom fault handler to customize
this? I guess that the fundamental problem that I am trying to solve
is that the fault handler does not allow initialization/configuration
parameters to be passed to the new actor. I just don't understand why
it is wrong to want this.

The information I am trying to pass along is just an IP address to
what it should connect up to. If I am going about this the wrong way
please advise on how to configure the newly restarted actor, which may
have been instantiated from a request that came from a user over HTTP
that provided the information and is no longer connected. i.e. the
user initiated a long running process.

[Derek Wyatt]

It seems as though you think that a supervised actor is not just "restarted" but is newly created, yes?

The actor reference you have is still valid on a restarted actor. So in essence, what you're saying, "I need to know which one replaced it" is odd. Nothing "replaces" anything from your perspective.

If you have:

val a = actorOf[SomeActor].start

and that instance dies when it gets a "CommitSuicide" message, then the supervisor restarts it and you're good to go. Like this:

a ! CommitSuicide
a ! DoSomethingNice

The "DoSomethingNice" message is handled just fine. I don't need to, somehow, figure out what the new "a" would be.

In truth, your actor under the covers is recreated, yes, but the actor reference (i.e. "a") is still perfectly fine. That's kinda the beauty of it.
________________________________________
From: akka...@googlegroups.com [akka...@googlegroups.com] On Behalf Of Garry [ga...@dynafocus.com]
Sent: Thursday, June 23, 2011 11:32 AM
To: Akka User List
Subject: [akka-user] Re: Linking actors and trapping exit in akka 1.1.2

To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

[Garry]

Ok I understand that ActorRef does not change, however it does build a
new SomeActor that extends Actor. The problem is I want to do this

val a = actorOf(new SomeActor("127.0.0.1")).start

OR if I could specify parameters to pass to the thing in the fault
handler configuration that get called to the preStart() is all I want

val config = Map("ipAddress", "127.0.0.1")

self.faultHandler =
Supervision.OneForOneStrategy(List(classOf[Exception]), 5, 1000,
config)

Thanks

> ...
>
> read more »

[Derek Wyatt]

What you're saying still works. The parameter "new SomeActor("127.0.0.1")" is a factory method. As such, when the actor is recreated, the same factory method will be used. It gets recreated /in exactly the same way as it was created originally/. You don't need a config map.

________________________________________
From: akka...@googlegroups.com [akka...@googlegroups.com] On Behalf Of Garry [ga...@dynafocus.com]

Sent: Thursday, June 23, 2011 11:59 AM

Thanks

--

[Garry]

How do I specify that? I am new to akka/scala so I may have missed it
somewhere (more likely don't understand it).

Thanks

> ...
>
> read more »

[Jonas Bonér]

And all the messages in the mailbox are retained. You can even send messages to the actor while it is being restarted. 

-- 

Jonas Bonér

CTO 

Typesafe - Enterprise-Grade Scala from the Experts

Phone: +46 733 777 123

Twitter: @jboner

[Jonas Bonér]

On Thursday, June 23, 2011 at 6:17 PM, Garry wrote:

Would it be like this?

val supervisor = Supervisor(
SupervisorConfig(
AllForOneStrategy(List(classOf[Exception]), 3, 1000),
Supervise(
actorOf(new SomeActor("127.0.0.1")),
Permanent) ::
Supervise(
actorOf[MyActor2],
Permanent) ::
Nil))

If so I didn't realize that the actorOf(...) lazily instantiated the
new actor.

It does.  

If that is true, I am happy with this scenario, and this discussion
has been a good learning tool for me. I apologize to anyone if I
annoyed you.

You have not. :-) 

Thanks
Garry

On Jun 23, 12:07 pm, Garry <ga...@dynafocus.com> wrote:

How do I specify that?  I am new to akka/scala so I may have missed it
somewhere (more likely don't understand it).

Thanks

On Jun 23, 12:03 pm, Derek Wyatt <dwy...@rim.com> wrote:

What you're saying still works.  The parameter "new SomeActor("127.0.0.1")" is a factory method.  As such, when the actor is recreated, the same factory method will be used.  It gets recreated /in exactly the same way as it was created originally/.  You don't need a config map.

________________________________________
From: akka...@googlegroups.com [akka...@googlegroups.com] On Behalf Of Garry [ga...@dynafocus.com]

Sent: Thursday, June 23, 2011 11:59 AM

To: Akka User List
Subject: [akka-user] Re: Linking actors and trapping exit in akka 1.1.2

Ok I understand that ActorRef does not change, however it does build a
new SomeActor that extends Actor.  The problem is I want to do this

val a = actorOf(new SomeActor("127.0.0.1")).start

OR if I could specify parameters to pass to the thing in the fault
handler configuration that get called to the preStart() is all I want

val config = Map("ipAddress", "127.0.0.1")

self.faultHandler =

Supervision.OneForOneStrategy(List(classOf[Exception]), 5, 1000,
config)

Thanks

...

read more »

[Garry]

One final question. It appears that self.supervisor is not assignable
because it is protected. So I have to create another
akka.config.Supervisor outside of the Supervisor class of the example
that we have been using, to assign the factory to the actor. Is that
correct? If that is true it would be really nice to be able to put
that into the faultHandler.

Thanks again Jonas and all for helping me understand.

On Jun 23, 12:23 pm, Jonas Bonér <jo...@jonasboner.com> wrote:
> On Thursday, June 23, 2011 at 6:17 PM, Garry wrote:
> > Would it be like this?
>
> > val supervisor = Supervisor(
> >  SupervisorConfig(
> >  AllForOneStrategy(List(classOf[Exception]), 3, 1000),
> >  Supervise(
> >  actorOf(new SomeActor("127.0.0.1")),
> >  Permanent) ::
> >  Supervise(
> >  actorOf[MyActor2],
> >  Permanent) ::
> >  Nil))
>
> > If so I didn't realize that the actorOf(...) lazily instantiated the
> > new actor.
>
> It does.
> > If that is true, I am happy with this scenario, and this discussion
> > has been a good learning tool for me. I apologize to anyone if I
> > annoyed you.
>
> You have not. :-)
> > Thanks
> > Garry
>

> > On Jun 23, 12:07 pm, Garry <ga...@dynafocus.com (http://dynafocus.com)> wrote:
> > > How do I specify that? I am new to akka/scala so I may have missed it
> > > somewhere (more likely don't understand it).
>
> > > Thanks
>

> > > On Jun 23, 12:03 pm, Derek Wyatt <dwy...@rim.com (http://rim.com)> wrote:
>
> > > > What you're saying still works. The parameter "new SomeActor("127.0.0.1")" is a factory method. As such, when the actor is recreated, the same factory method will be used. It gets recreated /in exactly the same way as it was created originally/. You don't need a config map.
> > > > ________________________________________

> > > > From: akka...@googlegroups.com (mailto:akka...@googlegroups.com) [akka...@googlegroups.com (mailto:akka...@googlegroups.com)] On Behalf Of Garry [ga...@dynafocus.com (http://dynafocus.com)]

> > > > Sent: Thursday, June 23, 2011 11:59 AM
> > > > To: Akka User List
> > > > Subject: [akka-user] Re: Linking actors and trapping exit in akka 1.1.2
>
> > > > Ok I understand that ActorRef does not change, however it does build a
> > > > new SomeActor that extends Actor. The problem is I want to do this
>
> > > > val a = actorOf(new SomeActor("127.0.0.1")).start
>
> > > > OR if I could specify parameters to pass to the thing in the fault
> > > > handler configuration that get called to the preStart() is all I want
>
> > > > val config = Map("ipAddress", "127.0.0.1")
>
> > > > self.faultHandler =
> > > > Supervision.OneForOneStrategy(List(classOf[Exception]), 5, 1000,
> > > > config)
>
> > > > Thanks
>

> > > > On Jun 23, 11:41 am, Derek Wyatt <dwy...@rim.com (http://rim.com)> wrote:
>
> > > > > It seems as though you think that a supervised actor is not just "restarted" but is newly created, yes?
>
> > > > > The actor reference you have is still valid on a restarted actor. So in essence, what you're saying, "I need to know which one replaced it" is odd. Nothing "replaces" anything from your perspective.
>
> > > > > If you have:
>
> > > > > val a = actorOf[SomeActor].start
>
> > > > > and that instance dies when it gets a "CommitSuicide" message, then the supervisor restarts it and you're good to go. Like this:
>
> > > > > a ! CommitSuicide
> > > > > a ! DoSomethingNice
>
> > > > > The "DoSomethingNice" message is handled just fine. I don't need to, somehow, figure out what the new "a" would be.
>
> > > > > In truth, your actor under the covers is recreated, yes, but the actor reference (i.e. "a") is still perfectly fine. That's kinda the beauty of it.
> > > > > ________________________________________

> > > > > From: akka...@googlegroups.com (mailto:akka...@googlegroups.com) [akka...@googlegroups.com (mailto:akka...@googlegroups.com)] On Behalf Of Garry [ga...@dynafocus.com (http://dynafocus.com)]

> > > > > Sent: Thursday, June 23, 2011 11:32 AM
> > > > > To: Akka User List
> > > > > Subject: [akka-user] Re: Linking actors and trapping exit in akka 1.1.2
>
> > > > > Q: Why do you want to interfere with the supervisor management? It is
> > > > > against the whole idea.
>
> > > > > I have a hierarchy of actors that act like a router down the tree. So
> > > > > if one dies I need to know which one replaced it so I can remove/add
> > > > > it back to my list so I can send new messages to it.
>
> > > > > Do I just need to write my own custom fault handler to customize
> > > > > this? I guess that the fundamental problem that I am trying to solve
> > > > > is that the fault handler does not allow initialization/configuration
> > > > > parameters to be passed to the new actor. I just don't understand why
> > > > > it is wrong to want this.
>
> > > > > The information I am trying to pass along is just an IP address to
> > > > > what it should connect up to. If I am going about this the wrong way
> > > > > please advise on how to configure the newly restarted actor, which may
> > > > > have been instantiated from a request that came from a user over HTTP
> > > > > that provided the information and is no longer connected. i.e. the
> > > > > user initiated a long running process.
>

> ...
>
> read more »

[Garry]

Would it be like this?

val supervisor = Supervisor(
SupervisorConfig(
AllForOneStrategy(List(classOf[Exception]), 3, 1000),
Supervise(
actorOf(new SomeActor("127.0.0.1")),
Permanent) ::
Supervise(
actorOf[MyActor2],
Permanent) ::
Nil))

If so I didn't realize that the actorOf(...) lazily instantiated the
new actor.

If that is true, I am happy with this scenario, and this discussion
has been a good learning tool for me. I apologize to anyone if I
annoyed you.

Thanks
Garry

> ...
>
> read more »

[Jonas Bonér]

I don't understand. You don't have to use the Supervisor class, any actor can be a supervisor. See the docs. 

-- 

Jonas Bonér

CTO 

Typesafe - Enterprise-Grade Scala from the Experts

Phone: +46 733 777 123

Twitter: @jboner

[Garry]

I have looked at the documentation about 20 times, I just don't
understand how I specify a factory to instantiate a new
Worker("127.0.0.1") that is supervised by an Actor with a
faultHandler. Otherwise where do i specify this:

Supervise(actorOf(new Worker(ipAddress)), Permanent), where ipAddress
is a val on the supervising actor.

Please modify this code to show me how to do it:

class Supervisor(val ipAddress:String) extends Actor {
self.faultHandler =
Supervision.OneForOneStrategy(List(classOf[Exception]), 5, 1000)

override def preStart(): Unit = {

EventHandler.info(this, "preStart of supervisor " +

self.id)
}
override def postStop() = {

EventHandler.info(this, "postStop of supervisor " +

self.id)
}
override def preRestart(err:Throwable) = {

EventHandler.info(this, "preRestart of supervisor " +

self.id)
}
override def postRestart(err:Throwable) = {

EventHandler.info(this, "postRestart of supervisor " +

self.id)
}
protected def receive = {

case p => EventHandler.info(this, "Super " + p + " " +
self.id);

}
}




On Jun 23, 1:19 pm, Jonas Bonér <jo...@jonasboner.com> wrote:
> I don't understand. You don't have to use the Supervisor class, any actor can be a supervisor. See the docs.
>
> --

> Jonas BonérCTO
> Typesafe (http://www.typesafe.com/) - Enterprise-Grade Scala from the Experts
> Phone: +46 733 777 123
> Twitter: @jboner (http://twitter.com/jboner)
>
>
>
>
>
>
>

> On Thursday, June 23, 2011 at 6:58 PM, Garry wrote:
> > One final question. It appears that self.supervisor is not assignable
> > because it is protected. So I have to create another
> > akka.config.Supervisor outside of the Supervisor class of the example
> > that we have been using, to assign the factory to the actor. Is that
> > correct? If that is true it would be really nice to be able to put
> > that into the faultHandler.
>
> > Thanks again Jonas and all for helping me understand.
>

> ...
>
> read more »

[Derek Wyatt]

override def preStart(): Unit = {
EventHandler.info(this, "preStart of supervisor " + self.id)

self.startLink(actorOf(new Worker(ipAddress)))
}
________________________________________
From: akka...@googlegroups.com [akka...@googlegroups.com] On Behalf Of Garry [ga...@dynafocus.com]
Sent: Thursday, June 23, 2011 1:51 PM

--

You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Garry]

Thanks that did the trick. I was missing that connection. I put a
copy of my sample program for others to see if interested.

http://pastebin.com/xv09xszY

Thanks again for all of the help.
Garry

> ...
>
> read more »

[Peter Vlugter]

On 23/06/2011, at 7:03 PM, oxbow_lakes wrote:

> Thanks Peter - this makes sense. Except for one further question! I
>
> f the "Exit" message callbacks are passed up the supervisor hierarchy
> but *I* am not supposed to handle them, I'm still confused about how/
> where to put a hook in my program where I would call this method:
>
> def kaboom(msg : Any) = { println("unexpected actor exit " + msg);
> sys.exit(-1) }

You can use the postStop callback on an actor that shouldn't be stopped - since a supervised actor that can't be "handled" is stopped.

If you don't want your actor to know about this, you can move it up one level to the supervisor. If the supervisor doesn't cover the exception it will pass it up a level, and if the super-supervisor doesn't cover it then it will stop the supervisor.

[Peter Vlugter]

Here's an example, based on your original example:

import akka.actor._
import akka.config.Supervision.OneForOneStrategy

class Worker extends Actor {
def receive = {
case int: Int => throw new java.io.IOException("Yuk.")
case symbol: Symbol => sys.error("AAIIIE!")
case message => println(message)
}
}

class Supervisor extends Actor {
self.faultHandler = OneForOneStrategy(List(classOf[java.io.IOException]), 5, 1000)
def receive = { case _ => () }
override def postStop = {
println("That was unexpected!"); sys.exit(-1)
}
}

class Top extends Actor {
self.faultHandler = OneForOneStrategy(Nil, 5, 1000)
def receive = { case _ => () }
}

val top = Actor.actorOf[Top].start()
val supervisor = Actor.actorOf[Supervisor].start()
val worker = Actor.actorOf[Worker].start()

top link supervisor
supervisor link worker

worker ! "Hello"
worker ! 123
worker ! 'boom

[RPR]

I think the OP (maybe, maybe not) was sort of asking that with Scala
standard actors one can link actor S to W and via setting trapExit, S
can become aware of and "explicitly" handle a failure in W. However,
Akka actors seem to structured preclude S from ever learning of W's
failure.

I hit this when doing a minimal quick and dirty conversion from Scala
actors to Akka where in several cases I was handling a trapExit
explicitly. And still want to.

Accept for the moment that there are times when this is desirable,
then this appears to be "a" way. Have no clue if it is "the" way.

mport akka.actor.{Actor, ActorRef}

import akka.config.Supervision.OneForOneStrategy

class Worker extends Actor {

override def preRestart (t: Throwable) =
println ("W restart from " + t.getMessage)

def receive = {
case int: Int => throw new Exception("FAILED")
case message => println (message)
}

}

class Supervisor extends Actor {
import akka.actor.MaximumNumberOfRestartsWithinTimeRangeReached

self.faultHandler = OneForOneStrategy (List (classOf[Throwable]),
Some (0), None)

def receive = {
case MaximumNumberOfRestartsWithinTimeRangeReached (w,cnt,_,e) =>
println ("Worker failure detected: " + cnt.get.toString + ", " +
w.toString + " last with " + e.toString)
// handle the situation.

case m =>
println ("S got: " + m.toString)
}

}

object Main extends App {

def doIt () = {
val w = Actor.actorOf[Worker].start
val s = Actor.actorOf[Supervisor].start

s link w

Actor.spawn {
w ! "Hello"
w ! "one"
w ! 1
w ! "two"
w ! 2
w ! "three"
w ! 3
}
}

doIt()
}


FWIW, from the way ActorRef.requestRestartPermission (...) is written
_if_ a time window > 0 is given then setting the max retries amount
to 0 does not prevent at least one retry.

i.e. self.faultHandler = OneForOneStrategy (List
(classOf[Throwable]), 0, 1000) // 1 retry happens despite max retries
of 0

[Jonas Bonér]

First, filed a ticket for the bug you mention: 

https://www.assembla.com/spaces/akka/tickets/982-supervisor-bug--1-retry-happens-despite-max-retries-of-0

Second, regarding the explicit supervisor fault-handling. It is something that we have so far decided to not support. I believe that the essence of the let-it-crash model is to declaratively configure fault handling then delegate the management and enforcement of it to the runtime. 

However, I understand that some people want more control. 

We have recently discussed richer way of interacting with the fault-management. It is implemented now according to this ticket: https://www.assembla.com/spaces/akka/tickets/955-allow-passing-of-actor-state-to-the-new-instance-on-restart

Impl here: https://github.com/jboner/akka/commits/ticket955

Take a look to see if it solves your problem or if we need to think of another solution. 

On 4 July 2011 03:37, RPR <ray.r...@gmail.com> wrote:

I think the OP (maybe, maybe not) was sort of asking that with Scala

standard actors one can link actor S to W, and via setting trapExit, S

can become aware of and "explicitly" handle a failure in W.  However,

Akka actors seem structured to preclude S from ever learning of W's
failure and gaining explicit handling of the situation.

I hit this when doing a minimal quick and dirty conversion from Scala
actors to Akka where in several cases I was handling a trapExit
explicitly.  And still want to.

Accept for the moment that there are times when this is desirable,

though granted in the majority of cases having the restart(s) done
implicitly by the runtime is superior, then this appears to be "a"
way.  I have no clue if it is "the" way.

import akka.actor.{Actor, ActorRef}

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--

Jonas Bonér
CTO 

Typesafe - Enterprise-Grade Scala from the Experts

[Ray Racine]

Only using Akka actors for something like 24 hrs so I hesitate...

On Mon, Jul 4, 2011 at 4:03 AM, Jonas Bonér <jo...@jonasboner.com> wrote:

....

 

Second, regarding the explicit supervisor fault-handling. It is something that we have so far decided to not support. I believe that the essence of the let-it-crash model is to declaratively configure fault handling then delegate the management and enforcement of it to the runtime. 

Understand completely.

 

However, I understand that some people want more control.  

We have recently discussed richer way of interacting with the fault-management. It is implemented now according to this ticket: https://www.assembla.com/spaces/akka/tickets/955-allow-passing-of-actor-state-to-the-new-instance-on-restart

The faulted actor may take explicit control in the minting of its replacement.  Slightly dangerous, but with great power comes great responsibility.  As the general approach remains to use the initial actor factory method, seems fine.

 

Impl here: https://github.com/jboner/akka/commits/ticket955

Take a look to see if it solves your problem or if we need to think of another solution. 

There were 2 specific points.

1) Anyone attempting a naive quick and dirty port from current Scala Actors to Akka will hit the explicit Exit (_,_) issue.   Definitely an FAQ in the "Porting Scala to Akka Actors Guide".  With the bug fixed, then declaring the appropriate restart strategy policy and handling the MaximumNumberOfRetriesWithTimeRange offers similar semantics for "rapid" porting.

2) The open question was not necessarily the degree of explicit control granted in a faulted actors reincarnation, it is the degree of explicit awareness of the supervising actor that a supervised worker has faulted and been successfully reincarnated.  Given that a reincarnated actor is both aware of its rebirth and the cause of its predecessors demise it can always inform any interested party explicitly of its resurrection.  I don't know if say a standardized Reborn message should be issued to the supervising actor by the declarative restart system.  Currently the supervising actor's behavior is autonomic and performed in blissful ignorance.

[Roland Kuhn]

On Jul 5, 2011, at 4:38, Ray Racine <ray.r...@gmail.com> wrote:

Only using Akka actors for something like 24 hrs so I hesitate...

On Mon, Jul 4, 2011 at 4:03 AM, Jonas Bonér <jo...@jonasboner.com> wrote:

....

 

Second, regarding the explicit supervisor fault-handling. It is something that we have so far decided to not support. I believe that the essence of the let-it-crash model is to declaratively configure fault handling then delegate the management and enforcement of it to the runtime. 

Understand completely.

 

However, I understand that some people want more control.  

We have recently discussed richer way of interacting with the fault-management. It is implemented now according to this ticket: https://www.assembla.com/spaces/akka/tickets/955-allow-passing-of-actor-state-to-the-new-instance-on-restart

The faulted actor may take explicit control in the minting of its replacement.  Slightly dangerous, but with great power comes great responsibility.  As the general approach remains to use the initial actor factory method, seems fine.

 

Impl here: https://github.com/jboner/akka/commits/ticket955

Take a look to see if it solves your problem or if we need to think of another solution. 

There were 2 specific points.

1) Anyone attempting a naive quick and dirty port from current Scala Actors to Akka will hit the explicit Exit (_,_) issue.   Definitely an FAQ in the "Porting Scala to Akka Actors Guide".  With the bug fixed, then declaring the appropriate restart strategy policy and handling the MaximumNumberOfRetriesWithTimeRange offers similar semantics for "rapid" porting.

2) The open question was not necessarily the degree of explicit control granted in a faulted actors reincarnation, it is the degree of explicit awareness of the supervising actor that a supervised worker has faulted and been successfully reincarnated.  Given that a reincarnated actor is both aware of its rebirth and the cause of its predecessors demise it can always inform any interested party explicitly of its resurrection.  I don't know if say a standardized Reborn message should be issued to the supervising actor by the declarative restart system.  Currently the supervising actor's behavior is autonomic and performed in blissful ignorance.

This is probably where Viktor’s idea of lifecycle observers comes into play: while the automatisms stay in place for the actual restarting, anyone may register himself to receive Started/Restarted/Stopped messages. Maybe as an “optimization” the supervisor could get the Restarted directly after processing the Exit without queuing again. 

[Jonas Bonér]

On 5 July 2011 07:18, Roland Kuhn <goo...@rkuhn.info> wrote:

On Jul 5, 2011, at 4:38, Ray Racine <ray.r...@gmail.com> wrote:

Only using Akka actors for something like 24 hrs so I hesitate...

On Mon, Jul 4, 2011 at 4:03 AM, Jonas Bonér <jo...@jonasboner.com> wrote:

....

 

Second, regarding the explicit supervisor fault-handling. It is something that we have so far decided to not support. I believe that the essence of the let-it-crash model is to declaratively configure fault handling then delegate the management and enforcement of it to the runtime. 

Understand completely.

 

However, I understand that some people want more control.  

We have recently discussed richer way of interacting with the fault-management. It is implemented now according to this ticket: https://www.assembla.com/spaces/akka/tickets/955-allow-passing-of-actor-state-to-the-new-instance-on-restart

The faulted actor may take explicit control in the minting of its replacement.  Slightly dangerous, but with great power comes great responsibility.  As the general approach remains to use the initial actor factory method, seems fine.

 

Impl here: https://github.com/jboner/akka/commits/ticket955

Take a look to see if it solves your problem or if we need to think of another solution. 

There were 2 specific points.

1) Anyone attempting a naive quick and dirty port from current Scala Actors to Akka will hit the explicit Exit (_,_) issue.   Definitely an FAQ in the "Porting Scala to Akka Actors Guide".  With the bug fixed, then declaring the appropriate restart strategy policy and handling the MaximumNumberOfRetriesWithTimeRange offers similar semantics for "rapid" porting.

2) The open question was not necessarily the degree of explicit control granted in a faulted actors reincarnation, it is the degree of explicit awareness of the supervising actor that a supervised worker has faulted and been successfully reincarnated.  Given that a reincarnated actor is both aware of its rebirth and the cause of its predecessors demise it can always inform any interested party explicitly of its resurrection.  I don't know if say a standardized Reborn message should be issued to the supervising actor by the declarative restart system.  Currently the supervising actor's behavior is autonomic and performed in blissful ignorance.

This is probably where Viktor’s idea of lifecycle observers comes into play: while the automatisms stay in place for the actual restarting, anyone may register himself to receive Started/Restarted/Stopped messages. Maybe as an “optimization” the

Yeah.

 

supervisor could get the Restarted directly after processing the Exit without queuing again. 

Sounds good.

[rkuhn]

Am Dienstag, 5. Juli 2011 09:00:48 UTC+2 schrieb Jonas Bonér:

On 5 July 2011 07:18, Roland Kuhn <goo...@rkuhn.info> wrote:

On Jul 5, 2011, at 4:38, Ray Racine <ray.r...@gmail.com> wrote:

Only using Akka actors for something like 24 hrs so I hesitate...

On Mon, Jul 4, 2011 at 4:03 AM, Jonas Bonér <jo...@jonasboner.com> wrote:

....

 

Second, regarding the explicit supervisor fault-handling. It is something that we have so far decided to not support. I believe that the essence of the let-it-crash model is to declaratively configure fault handling then delegate the management and enforcement of it to the runtime. 

Understand completely.

 

However, I understand that some people want more control.  

We have recently discussed richer way of interacting with the fault-management. It is implemented now according to this ticket: https://www.assembla.com/spaces/akka/tickets/955-allow-passing-of-actor-state-to-the-new-instance-on-restart

The faulted actor may take explicit control in the minting of its replacement.  Slightly dangerous, but with great power comes great responsibility.  As the general approach remains to use the initial actor factory method, seems fine.

 

Impl here: https://github.com/jboner/akka/commits/ticket955

Take a look to see if it solves your problem or if we need to think of another solution. 

There were 2 specific points.

1) Anyone attempting a naive quick and dirty port from current Scala Actors to Akka will hit the explicit Exit (_,_) issue.   Definitely an FAQ in the "Porting Scala to Akka Actors Guide".  With the bug fixed, then declaring the appropriate restart strategy policy and handling the MaximumNumberOfRetriesWithTimeRange offers similar semantics for "rapid" porting.

2) The open question was not necessarily the degree of explicit control granted in a faulted actors reincarnation, it is the degree of explicit awareness of the supervising actor that a supervised worker has faulted and been successfully reincarnated.  Given that a reincarnated actor is both aware of its rebirth and the cause of its predecessors demise it can always inform any interested party explicitly of its resurrection.  I don't know if say a standardized Reborn message should be issued to the supervising actor by the declarative restart system.  Currently the supervising actor's behavior is autonomic and performed in blissful ignorance.

This is probably where Viktor’s idea of lifecycle observers comes into play: while the automatisms stay in place for the actual restarting, anyone may register himself to receive Started/Restarted/Stopped messages. Maybe as an “optimization” the

Yeah.

 

supervisor could get the Restarted directly after processing the Exit without queuing again. 

Sounds good.

Updated ticket https://www.assembla.com/spaces/akka/tickets/842-add-mechanism-to-let-supervisor-react-to-restart-in-custom-fashion

Due to other constraints I will probably not get to this before the weekend, though.

Regards,

Roland

[Jonas Bonér]

Thanks Roland. Very good. 

--

You received this message because you are subscribed to the Google Groups "Akka User List" group.

To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/ZH59Lg1ipsAJ.

To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.