My understanding is that we define Behavior and pass it on to the method ReceiveBuilder.onMessage while spawning an actor. Whenever the actor receives a message, the corresponding Behaviour is executed. For the discussion purpose, I call the amount of work done in response to a message as “Message task”. The Dispatcher will execute the Behavior in an available thread.
Please clarify the following queries;
Is there any limitation on the amount of work done inside a Behaviour?
Will a “Message task” be executed by the same thread or multiple threads based on its size?
There’s no limit to the amount of work done inside a behavior when processing a message. It’s entirely legal for a behavior to process a message by going into an infinite loop. Of course, “just because you can, doesn’t mean that you should”: to the extent that it makes sense given the problem you’re trying solve, it’s a good idea to break up the amount of work done in a message task.
One way to break up a message task is to do some work, then send a message to yourself describing the work remaining to be done. This allows the actor to do work in response to other messages, which may or may not be desirable.
The work done in the task is executed in one single thread, though that work can include scheduling work to be done in some other thread (the advice on “just because you can…” applies here: introducing another thread requires a lot of care and needs to be a conscious decision, because it substantially weakens the guarantees Akka provides). Note also that, in general, a message task executing on one thread entails no guarantees about which thread any other message task executes on (e.g. be very careful with anything which uses (even indirectly) thread-local state).