Late answer, but better late than never, I guess. I'd recommend that you try to model this without reaching for special custom mailboxes or dispatchers but instead try to model the use case with actors:
Making sure a worker splits up its work in smaller segments, sending a trigger to itself to trigger processing of next segment is a good way to be able to share updates that many workers can use, the messages are processed in the order they are put in the inbox, so this lets the worker go through all messages sent to it since last work-segment-start-message before it continues with the next. Work pulling is also almost always a better to organize work than balancing as it allows the worker to apply back pressure, see the distributed worker sample for one example of that: https://developer.lightbend.com/guides/akka-distributed-workers-scala/ -- Johan Akka Team On Wed, Dec 13, 2017 at 3:50 PM, Arnaud Malapert <[email protected]> wrote: > Dear akka users, > > I am starting with akka and trying to translate a muti-threaded/MPI > application to the actor paradigm. > I want to manage a set of workers with the following features : > - Balancing : balance workload across workers (the router uses a Balancing > Pool <https://doc.akka.io/docs/akka/current/routing.html#balancingpool>) > - Broadcast : send important updates that help the workers to execute jobs > (reduce runtime) > - Priority : recent updates must be read before each job start. > > But, the doc says: > *Do not use **Broadcast Messages > <https://doc.akka.io/docs/akka/current/routing.html#broadcast-messages>** > when you use **BalancingPool > <https://doc.akka.io/docs/akka/current/routing.html#balancing-pool>** for > routers, as described in **Specially Handled Messages > <https://doc.akka.io/docs/akka/current/routing.html#router-special-messages>* > *. * > Here is the story of my failure to find the right solution. > > Idea 1. Create a second group router that broadcasts the updates to > the workers. > Problem. Workers miss many updates. Performance degrades. However, it > works well with the SmallestMailboxPool > <https://doc.akka.io/docs/akka/current/routing.html#smallestmailboxpool> > because each worker has its own mailbox. > > Idea 2. Use some kind of 'updates pill'. Ask an actor to send updates > to the router before and after a job is taken by a worker. > Problem. Workers miss some updates. Performance sometimes degrades. > > Idea 3. Manage the message concurrent queue by myself, as before > Problem. It gives total control but, it is more complicated, > error-prone and scales less easily. > > Idea 4. Implement my own dispatcher > Problem. A little bit complicated for a beginner, no ? > > As it seems a common use case, I may get some help here. > > Best regards, > Arnaud > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/ > current/additional/faq.html > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
