Remember amount of active actors != amount of running processes, you can have 100 actors monitoring and/or ready to receive a task status but each actor will only execute something when it receives a message, the thing to be careful is the dispatcher for the real tasks, these I recommend you to create a Future per task and again, each task has its own logic and from time to time such task sends a message to the owning actor.
Another idea without killing this idea is to have a list of nodes in your tasks issuer and put them in a round robin logic, each time you issue a task, it will go to the next corresponding node in a cycle, but the monitoring idea there isn't much you can do about it anyway. HTH, Guido. On Friday, March 18, 2016 at 8:50:57 PM UTC, Filippo De Luca wrote: > > Thanks Guido, > I had in mind something very similar. > > A alternative solution I am thinking of, because I don't want more than > one process running at the same time on the same node, is using a cluster > aware router with one routee per node. > > When some actor send something like: > StartProces(...) > > the sender will be notified every now and then with the process progress > and with the final result. > > So I will have one Actor instance for each execution, lets call it > ProcessMonitor and one Actor instance for each node as executor. These will > be reused. > > I think I may work as I want. > > On 17 March 2016 at 21:20, Guido Medina <[email protected] <javascript:>> > wrote: > >> Hi Filippo, >> >> One idea (of many I guess): >> >> 1. Have a dispatcher for long running futures. >> 2. For each task create an actor and within that actor create a >> future that each time such task status changes it sends a message to its >> actor. >> 3. Query such actor to get statuses. >> >> The reason that you need an actor and a future is because an actor can do >> one thing at the time so you wouldn't be able to execute the job and query >> status at the same time, >> >> HTH, >> >> Guido. >> >> On Wednesday, March 16, 2016 at 10:02:25 PM UTC, Filippo De Luca wrote: >>> >>> Hi Guys, >>> I have a task to schedule a long term task on the cluster. I am thinking >>> to model this task as an Actor that got deployed remotely. What is the best >>> approach to do that? >>> I want to have a way to control the amount of concurrent process I run >>> in the cluster. >>> >>> Also the Actor that run the process, run it in a Future, and it only >>> monitor it by receiving update on the progress from the future. Should I >>> use a child actor instead? The idea is that, the actor should be query-able >>> to ask the progress status. >>> >>> Any help will be very welcome. >>> >>> >>> -- >> >>>>>>>>>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > > > [image: --] > Filippo De Luca > [image: http://]about.me/FilippoDeLuca > <http://about.me/FilippoDeLuca?promo=email_sig> > > -- >>>>>>>>>> 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.
