singleton actors

[Scott Parish]

It looks like singleton-actors[1] can cause strange bad things to happen. Having stumbled upon this personally i now find a stackoverflow thread[2], but still don't see anything in the documentation. Should there be something in the docs warning against using singleton objects so others don't have to stumble upon this?

Thanks

sRp

1| eg:

     object My extends Actor {...}

     system.actorOf(Props(My))

this compiles and runs just fine. In my case this only blew up when fault tolerance should have kicked in. It wasn't clear until diving into the code how bad of an idea this is.

2| http://stackoverflow.com/questions/5189075/use-singletons-in-akka-scala-actor 

[Roland Kuhn]

Hi Scott,

the meaning of Restart is explained here: http://doc.akka.io/docs/akka/2.0.1/general/supervision.html#What_Restarting_Means

This should explain why using singletons as actor instances is not a good idea. I agree that this warning is missing in other places in the docs, will add that now.

Nevertheless, it would be good to know what exactly “blew up”, so that we can tell whether there is a bug on the Akka side.

Regards,

Roland

--
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.

Roland Kuhn
Typesafe – The software stack for applications that scale.
twitter: @rolandkuhn

[√iktor Ҡlang]

Atleast now this is available in the archives! :-)

[Roland Kuhn]

Then let me add a few more things to this mysterious archive:

Re-reading the code below gave me the shivers, because

- creating a second actor of this “type” will be completely messed up in horrible ways, and there is nothing we can do against that

- depending on the exact timing of when classes are loaded is … brittle to say the least (your object might be created long before you want that to happen)

And to have the solution in the same archive: actors are singletons by virtue of their ActorRef which is created from specific Props. The Actor instance living inside an ActorRef is not supposed to be a singleton in the (anti-)pattern sense of the word.

Regards,

Roland

[Scott Parish]

It looks like if messages arrive fast enough (or something) after having thrown an exception, you can find yourself in your receive() with "context" being null. I haven't been able to reproduce this after switching away from the singleton.

And for what its worth, I don't really care about enforsing a singleton, the actor naming does that easy enough. I ran into this out of laziness thinking I only ever need one of these so I save myself writing "new".

sRp

[√iktor Ҡlang]

On Fri, May 25, 2012 at 1:25 PM, Scott Parish <srpa...@gmail.com> wrote:

It looks like if messages arrive fast enough (or something) after having thrown an exception, you can find yourself in your receive() with "context" being null. I haven't been able to reproduce this after switching away from the singleton.

And for what its worth, I don't really care about enforsing a singleton, the actor naming does that easy enough. I ran into this out of laziness thinking I only ever need one of these so I save myself writing "new".

class My extends Actor {

  def receive = { case some => ... }

}

system.actorOf(Props[My]) is pretty short

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Scott Parish]

On Fri, May 25, 2012 at 7:07 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

On Fri, May 25, 2012 at 1:25 PM, Scott Parish <srpa...@gmail.com> wrote:

It looks like if messages arrive fast enough (or something) after having thrown an exception, you can find yourself in your receive() with "context" being null. I haven't been able to reproduce this after switching away from the singleton.

And for what its worth, I don't really care about enforsing a singleton, the actor naming does that easy enough. I ran into this out of laziness thinking I only ever need one of these so I save myself writing "new".

class My extends Actor {

  def receive = { case some => ... }

}

system.actorOf(Props[My]) is pretty short

Yeah, after saying that it occurred to me more likely why i was doing it--my background is more c/c++, not at all java. In those languages you become trained in thinking about if you only need one of something and putting it on the stack rather then the heap. Obviously with a GC that's a mute point, but i've still been in that mode of thinking.

sRp