Will Akka actors replace Scala actors in the standard Scala distro?

19 replies

Sun, 2011-09-18, 05:59

Ken McDonald

Joined: 2011-02-13,

It would make sense to me from a software maintainability point of view, plus the fact that from what little I know Akka actors seem better than Scala actors--but all I've heard concretely is that the Akka actors will be part of the Typesafe stack.Thanks,Ken

Hi Ken,first off: Akka actors _are_ part of the Typesafe stack ;-)But to answer your main question, yes, Akka actors will replace the current scala.actor package in the distribution at some point. There will be a smooth transition, though, meaning that for at least one major Scala release both implementations will be offered in parallel, probably in separate jars to keep IDEs from offering conflicting content assist options. Looking at it from the scala.actor perspective there are three main differences to consider:- actor encapsulation: Akka does not make the Actor object visible to the outside, it is hidden behind ActorRef- mailbox model: Akka requires strict in-order processing while scala.actor offers Erlang style behavior changes- threads as target: Akka users do not have to concern themselves with java.lang.Thread, sending messages to it is not supportedThe first difference is crucial for a reliable actor model (i.e. disallow bypassing the mailbox) and also for distributed actor systems (remote, clustering), which means it cannot be bridged in a source-compatible way.The second difference concerns options on how to formulate the behavior of your actors internally, and we will provide an emulation layer for Erlang style “receive” (and scala.actor’s “react”) on top of Akka’s Actor.The third difference might not be all that important as no-one is using it anyway; … hey, you, don’t look away, if there’s something I should know please tell me! ;-)So, if there’s something big I have overlooked, please holler!Regards,RolandOn Sep 18, 2011, at 06:59 , Ken McDonald wrote:

It would make sense to me from a software maintainability point of view, plus the fact that from what little I know Akka actors seem better than Scala actors--but all I've heard concretely is that the Akka actors will be part of the Typesafe stack.Thanks,Ken

I was wondering how actors (in general) would work in the context of
Fork/Join API in Java 7. I was reading the Akka tutorial for Java,
calculating pi, and it seemed similar to what you could do with
Fork/Join, but fork join gives you a lot of other functionality like
work stealing. Or would it be the case you just implement Fork/Join
on top of Actors?

Cheers, Eric

On 2011-09-17 11:06 PM, Roland Kuhn wrote:

AFF40125-B7B1-4F66-BAD0-837D150E5F37 [at] rkuhn [dot] info" type="cite">Hi Ken,
first off: Akka actors _are_ part of the Typesafe stack ;-)
But to answer your main question, yes, Akka actors will
replace the current scala.actor package in the distribution at
some point. There will be a smooth transition, though, meaning
that for at least one major Scala release both implementations
will be offered in parallel, probably in separate jars to keep
IDEs from offering conflicting content assist options. Looking
at it from the scala.actor perspective there are three main
differences to consider:
- actor encapsulation: Akka does not make the Actor object
visible to the outside, it is hidden behind ActorRef
- mailbox model: Akka requires strict in-order processing
while scala.actor offers Erlang style behavior changes
- threads as target: Akka users do not have to concern
themselves with java.lang.Thread, sending messages to it is not
supported
The first difference is crucial for a reliable actor model
(i.e. disallow bypassing the mailbox) and also for distributed
actor systems (remote, clustering), which means it cannot be
bridged in a source-compatible way.
The second difference concerns options on how to formulate
the behavior of your actors internally, and we will provide an
emulation layer for Erlang style “receive” (and scala.actor’s
“react”) on top of Akka’s Actor.
The third difference might not be all that important as
no-one is using it anyway; … hey, you, don’t look away, if
there’s something I should know please tell me! ;-)
So, if there’s something big I have overlooked, please
holler!
Regards,
Roland
On Sep 18, 2011, at 06:59 , Ken McDonald wrote:

It would make sense to me from a
software maintainability point of view, plus the fact that
from what little I know Akka actors seem better than Scala
actors--but all I've heard concretely is that the Akka
actors will be part of the Typesafe stack.
Thanks,
Ken

Eric,Scala Actors use a modified version of the ForkJoinPool contained in Java 7 by default, so they benefit from work stealing and such (at a thread level, not an actor level). They also suffer from the weaknesses as well.http://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_9_1_final/src/f...I don't know if Akka supports using the ForkJoinPool out-of-the-box, but I imagine setting it up to do so would be trivial.-Erik

I was wondering how actors (in general) would work in the context of
Fork/Join API in Java 7. I was reading the Akka tutorial for Java,
calculating pi, and it seemed similar to what you could do with
Fork/Join, but fork join gives you a lot of other functionality like
work stealing. Or would it be the case you just implement Fork/Join
on top of Actors?

Fork/Join and actors live at different levels of abstraction, hence putting one in the context of the other may not be meaningful. F/J is a specific solution for managing threads when you want something parallelized which can be broken down recursively, which is why it is used by the parallel collections framework. The actor model—on the other hand—is a completely different approach to distributed computing, where the elementary cell contains well-protected private state and is accessible only via messages which are queued in its mailbox.It would of course be possible to implement F/J on a set of “dumb” stateless actors, which just perform some passed-in computation, which is what the π example does. However, this does not exercise all the strengths of encapsulation and fault-tolerance which are provided by the actor model. The main issue is that “thinking in actors” is really different from the traditional OO and functional approaches; one way to look at it is that actors are actually the most radical implementation of OO, being fully encapsulated.On the other side, I know that Viktor has looked into perhaps writing an Akka dispatcher based on Java’s F/J framework. Without using F/J, Akka already has wicked fast event-based scheduling with and without work-donating, so he would have to comment on the potential up- and down-sides of this.One more thing to consider is this: in an Akka application you get full control how many threads to allocate to each group of actors, including growing and shrinking policies, so that you can for example dedicate some cores to the low-latency paths (actors using PinnedDispatcher) while scaling out the rest. This flexibility and control is not possible with F/J, especially if there are multiple users of it in the same JVM.Hope that helps. In case you have more questions, I’m happy to answer them either on the scala or akka lists.Regards,Roland

Cheers, Eric

On 2011-09-17 11:06 PM, Roland Kuhn wrote:

AFF40125-B7B1-4F66-BAD0-837D150E5F37 [at] rkuhn [dot] info" type="cite">Hi Ken,
first off: Akka actors _are_ part of the Typesafe stack ;-)
But to answer your main question, yes, Akka actors will
replace the current scala.actor package in the distribution at
some point. There will be a smooth transition, though, meaning
that for at least one major Scala release both implementations
will be offered in parallel, probably in separate jars to keep
IDEs from offering conflicting content assist options. Looking
at it from the scala.actor perspective there are three main
differences to consider:
- actor encapsulation: Akka does not make the Actor object
visible to the outside, it is hidden behind ActorRef
- mailbox model: Akka requires strict in-order processing
while scala.actor offers Erlang style behavior changes
- threads as target: Akka users do not have to concern
themselves with java.lang.Thread, sending messages to it is not
supported
The first difference is crucial for a reliable actor model
(i.e. disallow bypassing the mailbox) and also for distributed
actor systems (remote, clustering), which means it cannot be
bridged in a source-compatible way.
The second difference concerns options on how to formulate
the behavior of your actors internally, and we will provide an
emulation layer for Erlang style “receive” (and scala.actor’s
“react”) on top of Akka’s Actor.
The third difference might not be all that important as
no-one is using it anyway; … hey, you, don’t look away, if
there’s something I should know please tell me! ;-)
So, if there’s something big I have overlooked, please
holler!
Regards,
Roland
On Sep 18, 2011, at 06:59 , Ken McDonald wrote:

It would make sense to me from a
software maintainability point of view, plus the fact that
from what little I know Akka actors seem better than Scala
actors--but all I've heard concretely is that the Akka
actors will be part of the Typesafe stack.
Thanks,
Ken

I am developing applications in Space Based Architecture, using SQL
Spaces. One of the application uses MatLab, but each MatLab instance is
a single thread, consequently you have to run multiple instances in
separate processes. In effect, each instance becomes a worker that can
be on the same multi-core system, or on somewhere else on the network,
and the space binds them altogether. It is convenient that you can use
Java RMI to communicate with the MatLab instances.

I was originally considering trying ForkJoinPool as a way to decompose
the computations and manage the workers, but since reading about Akka
I'm wondering if it might be better going down that route.

In some cases computations can take hours using a single MatLab
instance, so we are motivated to reduce this as the individual
computations are completely independent of each other.

As much as I would prefer to use Scala, I am the only one on the team
who understands Scala. Using the Java version of Akka seems like an
alternative to ForkJoinPool, so I was curious as to how much of an
alternative it might be, and what the pros and cons are.

Cheers, Eric

On 2011-09-18 8:02 AM, Erik Engbrecht wrote:
> Eric,
> Scala Actors use a modified version of the ForkJoinPool contained in
> Java 7 by default, so they benefit from work stealing and such (at a
> thread level, not an actor level). They also suffer from the
> weaknesses as well.
>
> http://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_9_1_final/src/f...
>
> I don't know if Akka supports using the ForkJoinPool out-of-the-box,
> but I imagine setting it up to do so would be trivial.
>
> -Erik

Actually I am fairly familiar with Actors having used the SR
Programming Language back in the 90's, and a couple of years ago I
wrote a prime numbers program in Scala using Actors as a way to play
with my home/hobby computer with 8 cores and 16 threads :-) -- it
was cool watching all 16 threads running at 90%.

The application I have in mind is using MatLab, which is single
threaded. However, you can run multiple instances in separate
processes, and use RMI to communicate with each instance.

I was imagining you could create one actor for each MatLab instance
(representing that well protected private state you mentioned), but
I was looking for something more effective than what is used in the
pi tutorial, like ForkJoinPool, which I would imagine might sit on
top of the actors level. On the other hand, perhaps f/j is overkill
for what I am trying to do.

This application lives in a Space Based Architecture, so workers can
be coordinated via the space. The specific application is we have a
list of colors, and we need to compute a recipe for each color, and
each computation for a recipe is completely independent of any other
recipe. In a trivial mindless approach you just throw all the work
requests for each recipe into the space and workers do the work and
return the results to the space, but I am worried about the overhead
of the space communications being too dominate. The next best
approach seem to decompose the computation into chunks, and have
each worker do one chunk. In reality there are issues of MatLab
instances having different contexts for different types of
computations, and then competition for which worker is running which
context, and if more than one person is doing computations with
different contexts, how do you distribute the work fairly as
switching contexts in MatLab is also an overhead.

One of the things that intrigued me about Akka was the
fault-tolerance nature of things - in particular how to handle some
worker failing somewhere if the system it is on goes down. Obviously
I need to read further...

I was wondering how
actors (in general) would work in the context of Fork/Join
API in Java 7. I was reading the Akka tutorial for Java,
calculating pi, and it seemed similar to what you could do
with Fork/Join, but fork join gives you a lot of other
functionality like work stealing. Or would it be the case
you just implement Fork/Join on top of Actors?

Fork/Join and actors live at different levels of
abstraction, hence putting one in the context of the other
may not be meaningful. F/J is a specific solution for
managing threads when you want something parallelized which
can be broken down recursively, which is why it is used by
the parallel collections framework. The actor model—on the
other hand—is a completely different approach to distributed
computing, where the elementary cell contains well-protected
private state and is accessible only via messages which are
queued in its mailbox.
It would of course be possible to implement F/J on a set
of “dumb” stateless actors, which just perform some
passed-in computation, which is what the π example does.
However, this does not exercise all the strengths of
encapsulation and fault-tolerance which are provided by the
actor model. The main issue is that “thinking in actors” is
really different from the traditional OO and functional
approaches; one way to look at it is that actors are
actually the most radical implementation of OO, being fully
encapsulated.
On the other side, I know that Viktor has looked into
perhaps writing an Akka dispatcher based on Java’s F/J
framework. Without using F/J, Akka already has wicked fast
event-based scheduling with and without work-donating, so he
would have to comment on the potential up- and down-sides of
this.
One more thing to consider is this: in an Akka
application you get full control how many threads to
allocate to each group of actors, including growing and
shrinking policies, so that you can for example dedicate
some cores to the low-latency paths (actors using
PinnedDispatcher) while scaling out the rest. This
flexibility and control is not possible with F/J, especially
if there are multiple users of it in the same JVM.
Hope that helps. In case you have more questions, I’m
happy to answer them either on the scala or akka lists.
Regards,
Roland

Cheers, Eric

On 2011-09-17 11:06 PM, Roland Kuhn wrote:

AFF40125-B7B1-4F66-BAD0-837D150E5F37 [at] rkuhn [dot] info" type="cite">Hi Ken,
first off: Akka actors _are_ part of the Typesafe
stack ;-)
But to answer your main question, yes, Akka actors
will replace the current scala.actor package in the
distribution at some point. There will be a smooth
transition, though, meaning that for at least one
major Scala release both implementations will be
offered in parallel, probably in separate jars to keep
IDEs from offering conflicting content assist options.
Looking at it from the scala.actor perspective there
are three main differences to consider:
- actor encapsulation: Akka does not make the Actor
object visible to the outside, it is hidden behind
ActorRef
- mailbox model: Akka requires strict in-order
processing while scala.actor offers Erlang style
behavior changes
- threads as target: Akka users do not have to
concern themselves with java.lang.Thread, sending
messages to it is not supported
The first difference is crucial for a reliable
actor model (i.e. disallow bypassing the mailbox) and
also for distributed actor systems (remote,
clustering), which means it cannot be bridged in a
source-compatible way.
The second difference concerns options on how to
formulate the behavior of your actors internally, and
we will provide an emulation layer for Erlang style
“receive” (and scala.actor’s “react”) on top of Akka’s
Actor.
The third difference might not be all that
important as no-one is using it anyway; … hey, you,
don’t look away, if there’s something I should know
please tell me! ;-)
So, if there’s something big I have overlooked,
please holler!
Regards,
Roland
On Sep 18, 2011, at 06:59 , Ken McDonald wrote:

It would make sense to me
from a software maintainability point of view,
plus the fact that from what little I know Akka
actors seem better than Scala actors--but all I've
heard concretely is that the Akka actors will be
part of the Typesafe stack.
Thanks,
Ken

Hi Eric,you might want to consider using (remote) actors instead of RMI, simply because of the asynchronous nature of your problem. And with what the Akka 2.x series will offer, things are looking even brighter; more on that from Jonas in a short while.Wrapping each MatLab instance in one actor would be exactly the approach I would have suggested. That way you retain full control over how to scale out your application.Regards,RolandOn Sep 18, 2011, at 18:27 , Eric Kolotyluk wrote:

Actually I am fairly familiar with Actors having used the SR
Programming Language back in the 90's, and a couple of years ago I
wrote a prime numbers program in Scala using Actors as a way to play
with my home/hobby computer with 8 cores and 16 threads :-) -- it
was cool watching all 16 threads running at 90%.

The application I have in mind is using MatLab, which is single
threaded. However, you can run multiple instances in separate
processes, and use RMI to communicate with each instance.

I was imagining you could create one actor for each MatLab instance
(representing that well protected private state you mentioned), but
I was looking for something more effective than what is used in the
pi tutorial, like ForkJoinPool, which I would imagine might sit on
top of the actors level. On the other hand, perhaps f/j is overkill
for what I am trying to do.

This application lives in a Space Based Architecture, so workers can
be coordinated via the space. The specific application is we have a
list of colors, and we need to compute a recipe for each color, and
each computation for a recipe is completely independent of any other
recipe. In a trivial mindless approach you just throw all the work
requests for each recipe into the space and workers do the work and
return the results to the space, but I am worried about the overhead
of the space communications being too dominate. The next best
approach seem to decompose the computation into chunks, and have
each worker do one chunk. In reality there are issues of MatLab
instances having different contexts for different types of
computations, and then competition for which worker is running which
context, and if more than one person is doing computations with
different contexts, how do you distribute the work fairly as
switching contexts in MatLab is also an overhead.

One of the things that intrigued me about Akka was the
fault-tolerance nature of things - in particular how to handle some
worker failing somewhere if the system it is on goes down. Obviously
I need to read further...

I was wondering how
actors (in general) would work in the context of Fork/Join
API in Java 7. I was reading the Akka tutorial for Java,
calculating pi, and it seemed similar to what you could do
with Fork/Join, but fork join gives you a lot of other
functionality like work stealing. Or would it be the case
you just implement Fork/Join on top of Actors?

Fork/Join and actors live at different levels of
abstraction, hence putting one in the context of the other
may not be meaningful. F/J is a specific solution for
managing threads when you want something parallelized which
can be broken down recursively, which is why it is used by
the parallel collections framework. The actor model—on the
other hand—is a completely different approach to distributed
computing, where the elementary cell contains well-protected
private state and is accessible only via messages which are
queued in its mailbox.
It would of course be possible to implement F/J on a set
of “dumb” stateless actors, which just perform some
passed-in computation, which is what the π example does.
However, this does not exercise all the strengths of
encapsulation and fault-tolerance which are provided by the
actor model. The main issue is that “thinking in actors” is
really different from the traditional OO and functional
approaches; one way to look at it is that actors are
actually the most radical implementation of OO, being fully
encapsulated.
On the other side, I know that Viktor has looked into
perhaps writing an Akka dispatcher based on Java’s F/J
framework. Without using F/J, Akka already has wicked fast
event-based scheduling with and without work-donating, so he
would have to comment on the potential up- and down-sides of
this.
One more thing to consider is this: in an Akka
application you get full control how many threads to
allocate to each group of actors, including growing and
shrinking policies, so that you can for example dedicate
some cores to the low-latency paths (actors using
PinnedDispatcher) while scaling out the rest. This
flexibility and control is not possible with F/J, especially
if there are multiple users of it in the same JVM.
Hope that helps. In case you have more questions, I’m
happy to answer them either on the scala or akka lists.
Regards,
Roland

Cheers, Eric

On 2011-09-17 11:06 PM, Roland Kuhn wrote:

AFF40125-B7B1-4F66-BAD0-837D150E5F37 [at] rkuhn [dot] info" type="cite">Hi Ken,
first off: Akka actors _are_ part of the Typesafe
stack ;-)
But to answer your main question, yes, Akka actors
will replace the current scala.actor package in the
distribution at some point. There will be a smooth
transition, though, meaning that for at least one
major Scala release both implementations will be
offered in parallel, probably in separate jars to keep
IDEs from offering conflicting content assist options.
Looking at it from the scala.actor perspective there
are three main differences to consider:
- actor encapsulation: Akka does not make the Actor
object visible to the outside, it is hidden behind
ActorRef
- mailbox model: Akka requires strict in-order
processing while scala.actor offers Erlang style
behavior changes
- threads as target: Akka users do not have to
concern themselves with java.lang.Thread, sending
messages to it is not supported
The first difference is crucial for a reliable
actor model (i.e. disallow bypassing the mailbox) and
also for distributed actor systems (remote,
clustering), which means it cannot be bridged in a
source-compatible way.
The second difference concerns options on how to
formulate the behavior of your actors internally, and
we will provide an emulation layer for Erlang style
“receive” (and scala.actor’s “react”) on top of Akka’s
Actor.
The third difference might not be all that
important as no-one is using it anyway; … hey, you,
don’t look away, if there’s something I should know
please tell me! ;-)
So, if there’s something big I have overlooked,
please holler!
Regards,
Roland
On Sep 18, 2011, at 06:59 , Ken McDonald wrote:

It would make sense to me
from a software maintainability point of view,
plus the fact that from what little I know Akka
actors seem better than Scala actors--but all I've
heard concretely is that the Akka actors will be
part of the Typesafe stack.
Thanks,
Ken

Specifically the second paragraph under purpose. More generally along these lines, any FJ task that either blocks in an unmanaged way or runs continuously can cause starvation. If you have the FJ pool configured such that worker threads process their local dequeues in a LIFO manner you can also get surprising behavior.Basically the FJ pool is optimized for short, non-blocking computations, so you can decompose a task into lots of smaller tasks without worrying too much about the overhead of doing so.If you have long, blocking tasks you'd probably be better off using a different backing thread pool. I don't think Akka uses FJ by default, so if you use Akka you are probably good. If you use Scala Actors there's a flag you can set so it will use a ThreadPoolExecutor (I think) instead of the FJ pool.-Erik

Roland,I think Eric is shooting for something along these lines.Given N nodes with M cores each:1. There are N "Akka" processes, one per node2. Each "Akka" process contains M actors, each of which talk to Matlab via RMI (I'm guessing using the MatlabControl library)3. Each node runs up to M Matlab processes4. Each "Akka" process runs a supervisor actor that distributes work to the others, and restarts them if they die5. Nodes can farm out work to one another by sending jobs to the supervisor for that nodeAlternatively each Matlab process could run an actor in its own local JVM, and then the Matlab processes could talk to each other using remote actors. The problem is Matlab ships with it's own JRE, which is likely to be behind the times (especially if you are running an older version of Matlab). Matlab might also do funny things to its local JVM...I don't know. But anyway, since you can only have one Matlab engine per process, and each Matlab engine is for the most part single threaded, so if you want to take advantage of multiple cores you need multiple processes.-Erik

Roland,I think Eric is shooting for something along these lines.Given N nodes with M cores each:1. There are N "Akka" processes, one per node2. Each "Akka" process contains M actors, each of which talk to Matlab via RMI (I'm guessing using the MatlabControl library)3. Each node runs up to M Matlab processes4. Each "Akka" process runs a supervisor actor that distributes work to the others, and restarts them if they die5. Nodes can farm out work to one another by sending jobs to the supervisor for that node

Yes, this matches my intention.

Alternatively each Matlab process could run an actor in its own local JVM, and then the Matlab processes could talk to each other using remote actors. The problem is Matlab ships with it's own JRE, which is likely to be behind the times (especially if you are running an older version of Matlab). Matlab might also do funny things to its local JVM...I don't know. But anyway, since you can only have one Matlab engine per process, and each Matlab engine is for the most part single threaded, so if you want to take advantage of multiple cores you need multiple processes.

Thanks for explaining a bit deeper, this clears up the confusion in my previous mail.Regards,Roland KuhnTypesafe – Enterprise-Grade Scala from the Expertstwitter: @rolandkuhn

While you can run Java code within a MatLab instance, the instance is
single threaded, so far as I know you cannot start other Java threads.

Currently we use a Socket to communicate between the Java UI application
and the MatLab instance doing the work.

What the MatLab people do for web applications is launch one or more
MatLab processes, and the servlet communicates to the MatLab processes
via RMI, which is more elegant than what we do over a Socket.

Presumably one could run Akka code in the MatLab process, as long as it
is single threaded, or Just as easily the Akka process can use RMI to
get the MatLab processes to do work, with one Actor managing on MatLab
process.

In our new architecture there will be a service process running on each
node, that could contain the Akka based supervisor supporting all the
worker Actors. Initially we will be supporting only one node, but in the
future there will be multiple nodes. The Java UI application will post
work requests in the space, and the masters would watch the space, take
the request and coordinate the computations, then merge the results and
return the result to the space.

However, each node only needs to start and stop the MatLab processes,
once they are running, you could have a central master with all the
worker actors talking exclusively to each MatLab instance via RMI. If we
can run the Akka library in MatLab we could also implement the worker
actor in the MatLab process if that is better somehow.

Ultimately I am looking for the most simple architecture that is
efficient and reliable, and it is a space-based architecture.

Cheers, Eric

On 2011-09-18 10:13 AM, Erik Engbrecht wrote:
> Roland,
> I think Eric is shooting for something along these lines.
>
> Given N nodes with M cores each:
> 1. There are N "Akka" processes, one per node
> 2. Each "Akka" process contains M actors, each of which talk to Matlab
> via RMI (I'm guessing using the MatlabControl library)
> 3. Each node runs up to M Matlab processes
> 4. Each "Akka" process runs a supervisor actor that distributes work
> to the others, and restarts them if they die
> 5. Nodes can farm out work to one another by sending jobs to the
> supervisor for that node
>
> Alternatively each Matlab process could run an actor in its own local
> JVM, and then the Matlab processes could talk to each other using
> remote actors. The problem is Matlab ships with it's own JRE, which
> is likely to be behind the times (especially if you are running an
> older version of Matlab). Matlab might also do funny things to its
> local JVM...I don't know. But anyway, since you can only have one
> Matlab engine per process, and each Matlab engine is for the most part
> single threaded, so if you want to take advantage of multiple cores
> you need multiple processes.
>
> -Erik
>

On Sun, Sep 18, 2011 at 11:37, Eric Kolotyluk wrote:
> This is the first time I have ever heard of Akka, so I looked it up.
>
> I was wondering how actors (in general) would work in the context of
> Fork/Join API in Java 7. I was reading the Akka tutorial for Java,
> calculating pi, and it seemed similar to what you could do with Fork/Join,
> but fork join gives you a lot of other functionality like work stealing. Or
> would it be the case you just implement Fork/Join on top of Actors?

I find it curious that Roland didn't mention this, but you can
actually select the Executor for a group of actors. The default is
just an event-based, but there is a *work-stealing* event based
executor as well:

I guess you'd probably use that with this:http://akka.io/api/akka/1.1.3/#akka.routing.LoadBalancer. That way,
you send message to one actor who distributes it to others in a load
balancing fashion (this one is round-robin, but you can have more
sophisticated dispatchers), and these other actors having been
assigned a work stealing executor.

> On Sun, Sep 18, 2011 at 11:37, Eric Kolotyluk wrote:
>> This is the first time I have ever heard of Akka, so I looked it up.
>>
>> I was wondering how actors (in general) would work in the context of
>> Fork/Join API in Java 7. I was reading the Akka tutorial for Java,
>> calculating pi, and it seemed similar to what you could do with Fork/Join,
>> but fork join gives you a lot of other functionality like work stealing. Or
>> would it be the case you just implement Fork/Join on top of Actors?
>
> I find it curious that Roland didn't mention this, but you can
> actually select the Executor for a group of actors. The default is
> just an event-based, but there is a *work-stealing* event based
> executor as well:
>
> http://akka.io/api/akka/1.1.3/#akka.dispatch.ExecutorBasedEventDrivenWor...
>
Actually, while not giving this precise path, I hinted at it: I just called it “work-donating” dispatcher out of some weird reflex (because that term would be less imprecise from a technical standpoint, as I’m told by Viktor). More information on all choices here: http://akka.io/docs/akka/1.2-RC6/scala/dispatchers.html

> I guess you'd probably use that with this:
> http://akka.io/api/akka/1.1.3/#akka.routing.LoadBalancer. That way,
> you send message to one actor who distributes it to others in a load
> balancing fashion (this one is round-robin, but you can have more
> sophisticated dispatchers), and these other actors having been
> assigned a work stealing executor.
>

Yes, that’s the idea. And in 2.0 you will get all of this without having to think about it beforehand: just take your sufficiently state-less actor and outfit it with a pool, a router and a suitable dispatcher by adding this deployment to your configuration file.

I implemented a dispatcher based on FJ but after discussing it with Doug I decided to drop it (it had worse performance than the default dispatcher).
The reason is that it is, as the name states, designed for fork/join problems. With actors however, there is no join phase. It also doesn't seem to be dong work-stealing unless it's quiescing (sp?).

Now, the only remaining SPOBN of the default impl is the task queue of the thread pool executor, what would be interesting would be to stripe multiple and then rotate workers around, as there is no need for ordering of which mailboxes to execute, as long as there is low risk of starvation.

Cheers,
V

On Sep 19, 2011 8:24 AM, "Roland Kuhn" <google [at] rkuhn [dot] info> wrote:> > On Sep 19, 2011, at 03:43 , Daniel Sobral wrote:
> >> On Sun, Sep 18, 2011 at 11:37, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:>>> This is the first time I have ever heard of Akka, so I looked it up.
>>> >>> I was wondering how actors (in general) would work in the context of>>> Fork/Join API in Java 7. I was reading the Akka tutorial for Java,>>> calculating pi, and it seemed similar to what you could do with Fork/Join,
>>> but fork join gives you a lot of other functionality like work stealing. Or>>> would it be the case you just implement Fork/Join on top of Actors?>> >> I find it curious that Roland didn't mention this, but you can
>> actually select the Executor for a group of actors. The default is>> just an event-based, but there is a *work-stealing* event based>> executor as well:>> >> http://akka.io/api/akka/1.1.3/#akka.dispatch.ExecutorBasedEventDrivenWorkStealingDispatcher
>> > Actually, while not giving this precise path, I hinted at it: I just called it “work-donating” dispatcher out of some weird reflex (because that term would be less imprecise from a technical standpoint, as I’m told by Viktor). More information on all choices here: http://akka.io/docs/akka/1.2-RC6/scala/dispatchers.html
> >> I guess you'd probably use that with this:>> http://akka.io/api/akka/1.1.3/#akka.routing.LoadBalancer. That way,
>> you send message to one actor who distributes it to others in a load
>> balancing fashion (this one is round-robin, but you can have more>> sophisticated dispatchers), and these other actors having been>> assigned a work stealing executor.>> >
> Yes, that’s the idea. And in 2.0 you will get all of this without having to think about it beforehand: just take your sufficiently state-less actor and outfit it with a pool, a router and a suitable dispatcher by adding this deployment to your configuration file.
> > Roland Kuhn> Typesafe – Enterprise-Grade Scala from the Experts> twitter: @rolandkuhn>