Thanks Hazen for your explanation and your comment.
I hope I understood everything right! :) You want to split the work inside
an actor and use e. g. two executors, one for the actor stuff and one for
the heavy work (io...). But! It is important for me that the work of
message 1 is done befor
gt;> frees up akka to drive this executor as hard as it can.
>>
>> If you don't do this you're just moving your single threaded actor
>> handling from one dispatcher to the next, but aren't increasing internal
>> actor concurrency.
>>
>> -
Thanks again for your interesting points, jim
I already have a separate dispatcher for the actors and one for the system.
Am Mittwoch, 18. November 2015 18:30:13 UTC+1 schrieb Jim Hazen:
>
> That's possible. Your actor won't be able to get more work until it
> completes its receive. You could:
Am Mittwoch, 18. November 2015 00:39:46 UTC+1 schrieb Jim Hazen:
>
> Also, the default akka-remoting utilizing Java serialization is dog slow.
> There are other threads that discuss swapping out the serializer with much
> faster ones. So if you're doing a lot of cluster sharding, your through
Hallo everyone,
I have a question about CPU-usage and a large number of actors. I'm
currently playing with a server-system with 15 machines and each machine
has 2x Intel(R) Xeon(R) CPU E5-2450 v2 @ 2.50GH (8 Cores, 16 Threads for
each CPU)
I also have a measurement client which is one of the m
