Scheduling/Throttling a reaction

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Scheduling/Throttling a reaction

steve.nesbitt
All:

I'm sorry if this is an obvious question - I am still working on getting my
arms around java concurrency and GPARs

What is the correct way to throttle a reaction? Is it as simple as adding a
sleep to the loop?

The scenario I have is a web service actor which cannot send more than x
number of requests in a given time frame.

How do I model this in GPARs?

Thanks in advance,

-steve


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Scheduling/Throttling a reaction

Vaclav
Administrator
Hi Stephen,

you'll most likely have to do sleep in the actor body.

Cheers,

Vaclav


On Sat, Dec 12, 2009 at 1:58 AM, Stephen Nesbitt <[hidden email]> wrote:
All:

I'm sorry if this is an obvious question - I am still working on getting my
arms around java concurrency and GPARs

What is the correct way to throttle a reaction? Is it as simple as adding a
sleep to the loop?

The scenario I have is a web service actor which cannot send more than x
number of requests in a given time frame.

How do I model this in GPARs?

Thanks in advance,

-steve


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling/Throttling a reaction

Hamlet D'Arcy
> you'll most likely have to do sleep in the actor body.

You might consider using a ScheduledExecutorService to do the work.
Tasks submitted to an Executor service will return a Future object to
you, and you can then use Future.get() to block until completion. This
avoids the sleep() calls and avoid the issue of sleeping too long when
you don't need to be.

--
Hamlet D'Arcy
[hidden email]


On Sat, Dec 12, 2009 at 5:57 AM, Vaclav Pech <[hidden email]> wrote:

> Hi Stephen,
>
> you'll most likely have to do sleep in the actor body.
>
> Cheers,
>
> Vaclav
>
>
> On Sat, Dec 12, 2009 at 1:58 AM, Stephen Nesbitt
> <[hidden email]> wrote:
>>
>> All:
>>
>> I'm sorry if this is an obvious question - I am still working on getting
>> my
>> arms around java concurrency and GPARs
>>
>> What is the correct way to throttle a reaction? Is it as simple as adding
>> a
>> sleep to the loop?
>>
>> The scenario I have is a web service actor which cannot send more than x
>> number of requests in a given time frame.
>>
>> How do I model this in GPARs?
>>
>> Thanks in advance,
>>
>> -steve
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
>
> --
> E-mail: [hidden email]
> Blog: http://www.jroller.com/vaclav
> Linkedin page: http://www.linkedin.com/in/vaclavpech
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Scheduling/Throttling a reaction

steve.nesbitt
Hi Hamlet/Vaclav:

Thanks for the input.

When you say to put the sleep in the actor body - what exactly does that mean
(especially when I am extending AbstratPooledActor)

And I have considered a ScheduledExecutoService but - unless I'm mistaken -
this will require some sort of global/mutable counter to keep track of when
the last request was issued which then implies synchronized access to the
lookup and alteration of the counter. And I don't see a way to manage that
with GPARs.

Or am I missing something obvious?

Obviously my knowledge of concurrency is still formative (or shaky if you
prefer :-) Still I would think that what I want to do would be a fairly common
use case. But I haven't found much discussion or implementation examples.

Thx,

-steve

On Saturday 12 December 2009 05:29:27 am you wrote:

> > you'll most likely have to do sleep in the actor body.
>
> You might consider using a ScheduledExecutorService to do the work.
> Tasks submitted to an Executor service will return a Future object to
> you, and you can then use Future.get() to block until completion. This
> avoids the sleep() calls and avoid the issue of sleeping too long when
> you don't need to be.
>
> > Hi Stephen,
> >
> > you'll most likely have to do sleep in the actor body.
> >
> > Cheers,
> >
> > Vaclav
> >
> >
> > On Sat, Dec 12, 2009 at 1:58 AM, Stephen Nesbitt
> >
> > <[hidden email]> wrote:
> >> All:
> >>
> >> I'm sorry if this is an obvious question - I am still working on getting
> >> my
> >> arms around java concurrency and GPARs
> >>
> >> What is the correct way to throttle a reaction? Is it as simple as
> >> adding a
> >> sleep to the loop?
> >>
> >> The scenario I have is a web service actor which cannot send more than x
> >> number of requests in a given time frame.
> >>
> >> How do I model this in GPARs?
> >>
> >> Thanks in advance,
> >>
> >> -steve
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this list, please visit:
> >>
> >>    http://xircles.codehaus.org/manage_email
> >
> > --
> > E-mail: [hidden email]
> > Blog: http://www.jroller.com/vaclav
> > Linkedin page: http://www.linkedin.com/in/vaclavpech
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Scheduling/Throttling a reaction

Hamlet D'Arcy
What sort of throttling are we talking about?

Need to throttle back after more than 1000 events a second? Or
throttle back after more than 1 event per second? Are the events long
running or short lived?

--
Hamlet D'Arcy
[hidden email]


On Sat, Dec 12, 2009 at 11:25 AM, Stephen Nesbitt
<[hidden email]> wrote:

> Hi Hamlet/Vaclav:
>
> Thanks for the input.
>
> When you say to put the sleep in the actor body - what exactly does that mean
> (especially when I am extending AbstratPooledActor)
>
> And I have considered a ScheduledExecutoService but - unless I'm mistaken -
> this will require some sort of global/mutable counter to keep track of when
> the last request was issued which then implies synchronized access to the
> lookup and alteration of the counter. And I don't see a way to manage that
> with GPARs.
>
> Or am I missing something obvious?
>
> Obviously my knowledge of concurrency is still formative (or shaky if you
> prefer :-) Still I would think that what I want to do would be a fairly common
> use case. But I haven't found much discussion or implementation examples.
>
> Thx,
>
> -steve
>
> On Saturday 12 December 2009 05:29:27 am you wrote:
>> > you'll most likely have to do sleep in the actor body.
>>
>> You might consider using a ScheduledExecutorService to do the work.
>> Tasks submitted to an Executor service will return a Future object to
>> you, and you can then use Future.get() to block until completion. This
>> avoids the sleep() calls and avoid the issue of sleeping too long when
>> you don't need to be.
>>
>> > Hi Stephen,
>> >
>> > you'll most likely have to do sleep in the actor body.
>> >
>> > Cheers,
>> >
>> > Vaclav
>> >
>> >
>> > On Sat, Dec 12, 2009 at 1:58 AM, Stephen Nesbitt
>> >
>> > <[hidden email]> wrote:
>> >> All:
>> >>
>> >> I'm sorry if this is an obvious question - I am still working on getting
>> >> my
>> >> arms around java concurrency and GPARs
>> >>
>> >> What is the correct way to throttle a reaction? Is it as simple as
>> >> adding a
>> >> sleep to the loop?
>> >>
>> >> The scenario I have is a web service actor which cannot send more than x
>> >> number of requests in a given time frame.
>> >>
>> >> How do I model this in GPARs?
>> >>
>> >> Thanks in advance,
>> >>
>> >> -steve
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe from this list, please visit:
>> >>
>> >>    http://xircles.codehaus.org/manage_email
>> >
>> > --
>> > E-mail: [hidden email]
>> > Blog: http://www.jroller.com/vaclav
>> > Linkedin page: http://www.linkedin.com/in/vaclavpech
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Scheduling/Throttling a reaction

steve.nesbitt
On Saturday 12 December 2009 10:05:50 am you wrote:
> What sort of throttling are we talking about?
>
> Need to throttle back after more than 1000 events a second? Or
> throttle back after more than 1 event per second? Are the events long
> running or short lived?
>

Pretty long lived. I am supposed to guarantee that no more than 1 request will
be issued per second.

-steve

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Scheduling/Throttling a reaction

Hamlet D'Arcy
I'm not sure this is a good answer for GPars (or how GPars would
support it), but I would probably do this:

Stick all the requests into a queue
Create a ScheduledExecutorService that runs once a second
Have the executor task pull an item from the queue and submit

Someone else will have to explain how to make this groovy or gparsish.

--
Hamlet D'Arcy
[hidden email]



On Sat, Dec 12, 2009 at 12:12 PM, Stephen Nesbitt
<[hidden email]> wrote:

> On Saturday 12 December 2009 10:05:50 am you wrote:
>> What sort of throttling are we talking about?
>>
>> Need to throttle back after more than 1000 events a second? Or
>> throttle back after more than 1 event per second? Are the events long
>> running or short lived?
>>
>
> Pretty long lived. I am supposed to guarantee that no more than 1 request will
> be issued per second.
>
> -steve
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Scheduling/Throttling a reaction

Hamlet D'Arcy
As I think about it more, I think a scheduled executor is the way to go.

As the actor is instantiated, I'd created a ScheduledExecutor with a
thread pool size of 1 thread, scheduled once a second
As the actor is instantiated, initialize an ArrayBlockingQueue to hold
the tasks you'll eventually throttle
(http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ArrayBlockingQueue.html)
Lastly, as the actor is instantiated, put a task on the executor that
performs a take() on the queue and sends off the request to the
service you want. take() will block if there are no elements in the
queue, so there is no busy wait and no sleep.

Then, when a message is received, push it into the queue. If the queue
is empty, then the thread will be waiting at the take() call to pop it
off and execute it immediately. If the queue isn't empty then it will
wait to be processed at the rate of one element per second.

2 edge cases: ArrayBlockingQueue has a fixed size capacity. You'll
need to detect bottlenecks and avoid a cascading failure if things
back up. And scheduling a once-a-second executor means that your task
is fired /about/ every second... the interval between tasks might be
999 milliseconds sometimes and 1001 others.

--
Hamlet D'Arcy
[hidden email]



On Sat, Dec 12, 2009 at 7:05 PM, Hamlet D'Arcy <[hidden email]> wrote:

> I'm not sure this is a good answer for GPars (or how GPars would
> support it), but I would probably do this:
>
> Stick all the requests into a queue
> Create a ScheduledExecutorService that runs once a second
> Have the executor task pull an item from the queue and submit
>
> Someone else will have to explain how to make this groovy or gparsish.
>
> --
> Hamlet D'Arcy
> [hidden email]
>
>
>
> On Sat, Dec 12, 2009 at 12:12 PM, Stephen Nesbitt
> <[hidden email]> wrote:
>> On Saturday 12 December 2009 10:05:50 am you wrote:
>>> What sort of throttling are we talking about?
>>>
>>> Need to throttle back after more than 1000 events a second? Or
>>> throttle back after more than 1 event per second? Are the events long
>>> running or short lived?
>>>
>>
>> Pretty long lived. I am supposed to guarantee that no more than 1 request will
>> be issued per second.
>>
>> -steve
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Scheduling/Throttling a reaction

Hamlet D'Arcy
In reply to this post by Hamlet D'Arcy
Steve,

Here is the code to use a blocking queue and executor to do this in an
actor: http://svn.assembla.com/svn/SampleCode/throttle/src/org/sample/MyActor.groovy

It's explained in a blog post:
http://hamletdarcy.blogspot.com/2009/12/java-5-gpars-throttling-action.html

--
Hamlet D'Arcy
[hidden email]



On Sat, Dec 12, 2009 at 7:05 PM, Hamlet D'Arcy <[hidden email]> wrote:

> I'm not sure this is a good answer for GPars (or how GPars would
> support it), but I would probably do this:
>
> Stick all the requests into a queue
> Create a ScheduledExecutorService that runs once a second
> Have the executor task pull an item from the queue and submit
>
> Someone else will have to explain how to make this groovy or gparsish.
>
> --
> Hamlet D'Arcy
> [hidden email]
>
>
>
> On Sat, Dec 12, 2009 at 12:12 PM, Stephen Nesbitt
> <[hidden email]> wrote:
>> On Saturday 12 December 2009 10:05:50 am you wrote:
>>> What sort of throttling are we talking about?
>>>
>>> Need to throttle back after more than 1000 events a second? Or
>>> throttle back after more than 1 event per second? Are the events long
>>> running or short lived?
>>>
>>
>> Pretty long lived. I am supposed to guarantee that no more than 1 request will
>> be issued per second.
>>
>> -steve
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Scheduling/Throttling a reaction

Vaclav
Administrator
Very nice solution, indeed!
To generalize, if you want to throttle the speed of sending replies, the actor can put all out-going messages into a queue and have a scheduled executor periodically pop out a message from the queue and send it on to the target actor.

Vaclav



On Sun, Dec 13, 2009 at 2:22 PM, Hamlet D'Arcy <[hidden email]> wrote:
Steve,

Here is the code to use a blocking queue and executor to do this in an
actor: http://svn.assembla.com/svn/SampleCode/throttle/src/org/sample/MyActor.groovy

It's explained in a blog post:
http://hamletdarcy.blogspot.com/2009/12/java-5-gpars-throttling-action.html

--
Hamlet D'Arcy
[hidden email]



On Sat, Dec 12, 2009 at 7:05 PM, Hamlet D'Arcy <[hidden email]> wrote:
> I'm not sure this is a good answer for GPars (or how GPars would
> support it), but I would probably do this:
>
> Stick all the requests into a queue
> Create a ScheduledExecutorService that runs once a second
> Have the executor task pull an item from the queue and submit
>
> Someone else will have to explain how to make this groovy or gparsish.
>
> --
> Hamlet D'Arcy
> [hidden email]
>
>
>
> On Sat, Dec 12, 2009 at 12:12 PM, Stephen Nesbitt
> <[hidden email]> wrote:
>> On Saturday 12 December 2009 10:05:50 am you wrote:
>>> What sort of throttling are we talking about?
>>>
>>> Need to throttle back after more than 1000 events a second? Or
>>> throttle back after more than 1 event per second? Are the events long
>>> running or short lived?
>>>
>>
>> Pretty long lived. I am supposed to guarantee that no more than 1 request will
>> be issued per second.
>>
>> -steve
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech
Reply | Threaded
Open this post in threaded view
|

Re: Scheduling/Throttling a reaction

steve.nesbitt
In reply to this post by Hamlet D'Arcy
Hamlet:

This is tremendously helpful. Thank you very much.

You should probably add this scheduled barber implementation to the User docs.

Thanks again!

-steve



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Scheduling/Throttling a reaction

Hamlet D'Arcy
Thank you, it is nice to hear positive feedback.

A word of warning:

If you don't have enough customers in your waiting room then the
barber scheduled task will continue to post every 15 minutes anyway...
if you have no customers in 24 hours then your ArrayBlockingQueue will
have 96 take() calls built up! You'll probably want to fix this
problem before puttting it in production.

--
Hamlet D'Arcy
[hidden email]



On Mon, Dec 14, 2009 at 2:07 PM, Stephen Nesbitt
<[hidden email]> wrote:

> Hamlet:
>
> This is tremendously helpful. Thank you very much.
>
> You should probably add this scheduled barber implementation to the User docs.
>
> Thanks again!
>
> -steve
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Scheduling/Throttling a reaction

Hamlet D'Arcy
In reply to this post by steve.nesbitt
> You should probably add this scheduled barber implementation to the User docs.

If the gpars teams wants this in the gpars examples then I can create
a patch and send it in. Can a team member send me a private email if
you want it?

--
Hamlet D'Arcy
[hidden email]



On Mon, Dec 14, 2009 at 2:07 PM, Stephen Nesbitt
<[hidden email]> wrote:

> Hamlet:
>
> This is tremendously helpful. Thank you very much.
>
> You should probably add this scheduled barber implementation to the User docs.
>
> Thanks again!
>
> -steve
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email