Rate limited LiftActor

[Donald McLean]

I have a case where a LiftActor is handling messages too quickly and it is flooding another process with requests. Is there a way to throttle a LiftActor?

My first thought was to have the first actor pass the messages to a second actor with a delay, but it also seems like this could be a relatively common issue, so I thought I would ask here first.

Thank you,

Donald

[Antonio Salazar Cardozo]

Introducing a random jittered delay isn't a bad idea. Beyond that, I'd see if

you can throttle somewhere else, though… Throttling in an actual actor seems

like a hairy proposition unless you're willing to burn threads doing it.

Though honestly if you're trying to throttle, I guess sleeping an actor thread

isn't the worst way to do it, since that will naturally slow things down for the

other actors as well.

Thanks,

Antonio

[Alex Kotchnev]

Can the LiftActor (similarly to Akka actors) use a smaller pool size
to limit how many actor instances are handling incoming requests ?
Obviously, that's not quite the same as throttling the rate of
processing, but it could certainly help , especially if there are a
lot of incoming requests processed by a large actor pool.

Cheers - Alex K

> --
> --
> Lift, the simply functional web framework: http://liftweb.net
> Code: http://github.com/lift
> Discussion: http://groups.google.com/group/liftweb
> Stuck? Help us help you:
> https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to liftweb+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Donald McLean]

I created a solution that works. Not pretty, I'm sure.

It's based on a RateLimiter class that I put up for review:

http://codereview.stackexchange.com/questions/128241/rate-limiter-utility-class

--

Family photographs are a critical legacy for
ourselves and our descendants. Protect that
legacy with a digital backup and recovery plan.

[Antonio Salazar Cardozo]

I think all lift actors run in the same thread pool, so that wouldn't really

be a good solution since the issue here is that some actors are producing

more than can be handled by others (from my understanding).

It's worth noting that Lift's actors are kind of designed to be relatively simple.

More complex stuff is probably done with Akka. This doesn't mean we're not

interested in improving Lift actors if it makes sense, but we're also not looking

to make them a replacement for Akka. Lift actors are meant to be lightweight

and incredibly easy to get going with, as well as API-compatible so switching

to Akka is more a matter of setting up the Akka infrastructure for the actor

itself rather than updating all the things talking to the actor.

Thanks,

Antonio

> email to liftweb+unsubscribe@googlegroups.com.

[Donald McLean]

That's a good point, Antonio, and one of the things I really like about Lift actors.

Thanks for the reminder.

> email to liftweb+u...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--

--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.