CODEWITHSUNDEEP
akkaactorfuture
MaatDeamon
MaatDeamon

Reputation: 9761

Threading model and AKKA

I heard somewhere that by default an Actor system, meaning its ExecutorService/Dispatcher was creating a pool of Non-Deamon thread to run Actor. If it is indeed really the case, and that would explain some of the behavior i had experience, where in the documentation of AKKA can i find it. I mean in the last version of the documentation there is nothing that says it. It seams also that this has change in the mean time.

Some have used AwaitTermination in the main thread, to keep the program from not shutting down the actor system that is running. I have seen code snippet like that.

But then i realize that is it not useful.

Still Puzzle by that behavior i went on to experiment with futures, but it did not work and i had to block on my main. However when used within an Actor it works. Well that's because the future is running in a daemon thread.

Those difference are quite important to understand.

When one import ExecutionContext.implicit.global :

1 - when running a future, is the execution context a threadPool of Deamon or non Deamon Thread

2 - when running a future within an Actor ? What happens, is it the same as importing inside the actor context.dispatcher ? In this case, when one start an Actorsystem, does the ExecutionContext.implicit.global value change to an executorService with a pool of non-daemon thread.

I would really appreciate if someone, could help me clarify a little, the value of ExecutionContext.implicit.global in the context of no actor but Future, in the context of Actor, and in the context of future within Actor ? In particular what kind of thread does it manage Deamon or non-deamon (with respect to the context cited before)? If possible, a documentation about it.

Upvotes: 3

Views: 1477

Answers (1)

Andriy Plokhotnyuk
Andriy Plokhotnyuk

Reputation: 7989

java.util.concurrent.ThreadFactory creates Deamon or non Deamon types of threads.

By default ExecutionContext.global uses ForkJoinPool with thread factory that produces daemon threads.

In akka configuration there is akka.daemonic property which is off by default (in reference.conf). This flag is used when creating default thread factory for default dispatchers and scheduler.

Best documentation is source code of Akka and Scala libraries.

I had similar problem of not shutdowning of Spray application in Tomcat container. With Java Mission Control I found that after succesfull shutdown of actor system the scheduler thread is sleeping in akka.actor.LightArrayRevolverScheduler.waitNanos(long). Setting of akka.daemonic = on fixed this problem.

Upvotes: 4

Related Questions