Hi Konard, I appreciate your response.
There are two approaches for work processing either pull or push. Pull seems to be better approach for processing work(http://blog.goconspire.com/post/64901258135/akka-at-conspire-part-5-the-importance-of-pulling). Note:Pull based work processing sample code(https://github.com/derekwyatt/akka-worker-pull). In Pull based approach, if producer is creating more work, we can implement a logic to add more worker actors to the system. These additional workers will take the surge of work created by fast producer. This maintain's balance or capability in the system to handle sudden load. Nothing against akka streams but it's back pressure will force the producer to push the work at slow rate. What are your thoughts on taking the approach of pull based processing with capability of adding more worker's or worker nodes on the fly? -Prakhyat M M On Wednesday, 6 August 2014 15:32:04 UTC+5:30, Akka Team wrote: > > Hi Prakhyat, > Just creating more actors can help with throughput, but if you don't > signal to a faster producer that it should slow down producing, it will > eventually stuff out all inboxes anyway. > > This is one of the reasons we're working on reactive-streams > <http://reactive-streams.org> which make dealing with back-pressure a > built-in thing (which is not true for Actors – they're a very generic tool). > > -- konrad > > > On Wed, Aug 6, 2014 at 9:36 AM, Prakhyat Mallikarjun <[email protected] > <javascript:>> wrote: > >> Hi Derek, >> >> Instead of PressureQueue, why you did not choose approach of creating >> more actors to take flood of requests from client? >> >> >> On Wednesday, 25 April 2012 17:55:25 UTC+5:30, Derek Wyatt wrote: >> >>> Don't sweat it. It's just a concept and I'm not in any rush to use it >>> any time soon. I'm glad you remembered, though. >>> >>> Cheers, >>> Derek >>> >>> On 2012-04-25, at 8:16 AM, Viktor Klang wrote: >>> >>> Hey Derek, >>> >>> >>> sorry for the delayed response on this, everyone's been busy with >>> ScalaDays. >>> I'll get to this as soon as my backlog decreases. >>> >>> Thanks for staying on top of things! >>> >>> Cheers, >>> √ >>> >>> >>> On Mon, Apr 16, 2012 at 1:52 PM, Derek Wyatt <[email protected]> >>> wrote: >>> >>>> Hi guys, >>>> >>>> A few days ago I talked about a queue that slows down its clients when >>>> it starts to get full. I decided to throw together a quick concept >>>> example >>>> so that I could get some feedback. >>>> >>>> The code can be found at: https://github.com/derekwyatt/ >>>> PressureQueue-Concept >>>> >>>> If you've got some time, I'd appreciate people taking a look at it to >>>> see what they think. I'll summarize the purpose here: >>>> >>>> When your Actor is working with an unfriendly API or a naturally >>>> limited system that doesn't deal well with tons of load, it would be nice >>>> if we can slow the clients down. If the client wants an answer within the >>>> next 10 seconds, but the queue's size dictates that it's going to take >>>> three hours anyway, then there's no point in letting the enqueue occur. >>>> In >>>> fact, letting it occur means that the work it's going to have to do >>>> because >>>> of that will be useless - the client is going to retry in 20 seconds >>>> anyway, or it's going to ignore the result. This sort of thing can lead >>>> to >>>> load death, or at the very least load spikes that aren't desirable. >>>> >>>> By purposely blocking the clients (yes, this is a blocking API) we get >>>> a "natural" throttling. If things are coded correctly, then the slowing >>>> down of the enqueue call propagates all the way back to the clients… >>>> >>>> As long as the WorkingActor has threads to do its work, the clients can >>>> block and not starve the WorkingActor. As the WorkingActor clears out its >>>> Mailbox, the enqueues start to speed up again, and slow down as the queue >>>> fills up. Smooth load curves instead of sharp spikes. That's the idea. >>>> >>>> Comments and flames are welcome :) >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Akka User List" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to akka-user+...@ >>> googlegroups.com. >>> >>> For more options, visit this group at http://groups.google.com/ >>> group/akka-user?hl=en. >>> >>> >>> -- >> >>>>>>>>>> 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 http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Akka Team > Typesafe - The software stack for applications that scale > Blog: letitcrash.com > Twitter: @akkateam > -- >>>>>>>>>> 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.
