Comments on Chariot Solutions: Learnings from Actor Development

Eurekin, Phillip Haller has book about to reach pr...

2011-07-07T14:07:38.213-04:00

Eurekin,
Phillip Haller has book about to reach print on this topic.

http://www.artima.com/shop/actors_in_scala

Eurekin, Would that I had the time. :) But if th...

2011-07-07T10:31:14.972-04:00

Eurekin,
Would that I had the time. :) But if there's anything specific you need to know, don't hesitate to ask. I can also be reached via twitter at @jamie_allen.

Would You mind writing a book about it? :D

2011-07-07T07:19:55.142-04:00

Would You mind writing a book about it? :D

Kai, I would definitely use Actors again, but only...

2011-07-05T15:20:46.498-04:00

Kai,
I would definitely use Actors again, but only where the situation warrants it. Actors are composable abstractions, allowing the developer to dictate logic flow via asynchronous interaction and guaranteed single-threaded access to shared state. When you have many consumers all attempting to access state at the same time, encapsulating that state in actors is safer than using multiple locks in several classes that could block one another.

I would not use an actor just to prevent using a lock or synchronized block in my code. Only once my design shows the interleaving of locks would I consider using an actor implementation. When I can reason about my locks/semaphores/mutexes/etc, then I am perfectly happy to stay with them.

Note that actors can also reduce latency in a system where work stealing is used to delegate tasks among a pool of actors. A dispatcher can have many actors working for it to handle load, and when one is finished it will send a message with the next task rather than using a less efficient strategy such as round robin, which doesn't take into account latency in a specific actor's execution of a task. Akka has a work-stealing dispatcher you can use in v1.1, and a ForkJoinDispatcher appears to be on the way for v2 soon.

Marc, Actors "die" when an uncaught exce...

2011-07-05T14:43:01.350-04:00

Marc,
Actors "die" when an uncaught exception occurs on their execution thread. This is by design, and is explained well in the "let it crash" paradigm espoused by Akka creator Jonas Bonér. The idea is that you cannot predict all possible scenarios where something can go wrong, so make your system fault tolerant by being able to recover appropriately no matter what happens. This is managed through how you "link" actors at runtime so that they notify others when they are dying. Akka also provides you with supervisory strategies for what to do when a linked actor dies: a) recreate only the one that died, or b) kill all other actors it is supervising and recreate all.

Hey Jamie, thank you for sharing your experiences...

2011-07-04T08:58:03.443-04:00

Hey Jamie,

thank you for sharing your experiences with actors.

After reading your learnings, I wonder what your conclusion is about using actors? Will you use them again or go back to the Thread programming model (Java improved the API with JDK 5/6/7, thus it is easier - but still complex - to use)?

I think that actors have a better abstraction level. You do not have to concern about shared memory, locks, and so on. Debugging is difficult as it is with Threads, so that's no obstacle.
I would like to use actors (either Scala API or even the Java or Scala API of Akka) in my next project, if management permits it :-)

Are there any reasons why you would not use actors instead of the Thread API?

Best regards,
Kai Wähner (Twitter: @KaiWaehner)

What makes actors fragile? Is there something spe...

2011-07-01T14:38:54.677-04:00

What makes actors fragile? Is there something specifically about Actor that makes them so or is it that they often represent things that naturally come and go?