Hi Eric and Heiko, doesn't the activator template for distributed workers also use a resilient (and persisted (?)) master to handle failure?
cheers, Martin Am 28.05.2014 17:31 schrieb "Heiko Seeberger" <[email protected]>: > On 28 May 2014, at 16:17, Eric Nelson <[email protected]> wrote: > > Heiko, that makes sense. I appreciate your reply. I was planning on using > an adaptive load balancing router to be smarter about what workers get > work. I'm wondering about other possible advantages to the "worker pulls > work" approach. One thing that comes to mind is that I'm constantly pushing > work to worker nodes, and the waiting jobs are piling up in the message > boxes of the workers. If a worker goes down, then my unprocessed messages > are lost. The worker pull mechanism seems safer in that it only takes one > job at a time and doesn't request another until it's completed its current > task. Could that be another advantage? > > > Well, in this case the unprocessed messages pile up at the master which > can also go down. Hence I wouldn’t consider that aspect an advantage. > > Heiko > > > Thanks again for any ideas. > > --Eric > > On Tuesday, May 27, 2014 11:16:30 PM UTC-6, Heiko Seeberger wrote: >> >> Eric, >> >> In your approach, the master is pushing work towards the workers whereas >> in the other approach the workers are pulling work (technically its still a >> push, but only after readiness has been signaled). The pull based approach >> might be advantageous if the work is not evenly distributed, e.g. because >> some messages need more time to be handled or the worker machines differ >> largely in capacity. >> >> Hoping this helps. >> >> Heiko >> >> >> On Wed, May 28, 2014 at 12:22 AM, Eric Nelson <[email protected]>wrote: >> >>> Hi all. I have a question based on the Activator template "akka >>> distributed workers". I have already written a system very similar to this >>> one. The main difference is that I don't have the workers register with the >>> master. The master simply uses a cluster-based router to round-robin out >>> work to anyone who is in the cluster with that worker path. This way, I >>> don't have the complexity of having the workers constantly having to send >>> out a registration message, I simply let the cluster router handle it with >>> any worker actor who is currently up and in the cluster. >>> >>> But I feel like I might be missing something that this registration >>> model provides, that maybe my views on this are too simplistic and there's >>> a good reason for this model. Can anyone help me in understanding what >>> might be the main deficiencies in my approach, and what I would gain by >>> having a registration mechanism from workers to master? (I am using the >>> Cluster Singleton approach for my Master actor, which works very nicely >>> because I only want on master at a time in the cluster, who pull in work >>> from a DB source, and distributes the work out to available worker actors). >>> >>> Any help and insight is greatly appreciated. I love Akka and the amazing >>> community behind it. >>> >>> --Eric >>> >>> -- >>> >>>>>>>>>> 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. >>> >> >> >> >> -- >> >> Heiko Seeberger >> Twitter: @hseeberger >> Blog: blog.heikoseeberger.name >> > > -- > >>>>>>>>>> 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. > > > > -- > > Heiko Seeberger > Twitter: @hseeberger > Blog: blog.heikoseeberger.name > > > > > -- > >>>>>>>>>> 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. > -- >>>>>>>>>> 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.
