8 maj 2014 kl. 23:06 skrev Eugene Dzhurinsky <[email protected]>: > On Thu, May 08, 2014 at 10:37:21PM +0200, Akka Team wrote: >> Hi Eugene, >> >> could you clarify the use-case a bit more? Why would there be multiple >> FSMs, where would the messages to be processed come from, why can’t you use >> the work pulling >> pattern<http://letitcrash.com/post/29044669086/balancing-workload-across-nodes-with-akka-2> >> ? > > Hello, Roland! Thanks for getting back to me. > > I have a queue of tasks to be processed. This queue is filled with data from > external monitoring system and user interactions. So users can "produce" tasks > as well as some events in the system can trigger a new task. > > Some of the tasks need to have rather big amount of work to be performed. In > order to do it more efficiently - I split the work in "chunks". These > "chunks" could be further split into individual records to be distributed > across the network of stateless actors. > > So the flow could be drawn as: > > - There is the cluster of actors. > - Task is delivered to actor A, which is FSM and has 2 states - Await and > Process. > - Actor A knows how to split the task into chunks, so it does so. > - Actor A knows about a set of actors B, because it watches the cluster to > receive MemberUp events from actors of role "B" > - Now actor A may split the task into chunks according to it's knowledge about > the number of available actors of role B, and send messages to every actor B. > - Actor B, upon receiving an event from A, sends a bunch of messages to all > actors of role C, and waits for responses from all of the actors C. So it's > implemented as FSM with states Await and Process. > > So far it works well, but this schema requires actor A to be a singleton > (since actors B can have a state, which doesn't allow them to receive a task > to be processed, and the only way to know that is to keep list of idle/busy > actors in A). > > Now I want to have several actors A, which may share number of actors B in > order to process large tasks. But I have no simple idea of how to know in > advance the state of an actor B prior sending it a message.
Since actors are distributed (even when running locally) one cannot possibly know about the “current” state of another. Therefore you need to turn it around and have B ask for more work when the old work has been finished. The remaining question then is: why do you need multiple A actors? The answer will also tell you how to distribute the requests for more work among them. Regards, Roland > > -- > Eugene N Dzhurinsky Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- >>>>>>>>>> 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
