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] > <javascript:>> 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] > <javascript:>. > To unsubscribe from this group, send email to > [email protected] <javascript:>. > 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]. 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.
