Re: Concurrency-interest Digest, Vol 121, Issue 8

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

Re: Concurrency-interest Digest, Vol 121, Issue 8

Valentin Kovalenko
>>is the purpose of rate limiter to control contention on the
executor thread pool /task queue/?
The purpose of fixed rate executor is exactly the following: to fire actions at the specified rate (not with higher rate, not with lower rate).

>>when the limit is reached, the requests.....ermmm.... wait somewhere in a
queue?
When the limit is reached, executor becomes idle till the start of next period.
Could you explain what do you mean by "requests?" I don't understand because there are no requests, there is only executor that fires actions (calls action.run()) and ensures that at each period not more that RATE actions were completed.


Date: Wed, 04 Feb 2015 12:55:53 +0000
From: Oleksandr Otenko <[hidden email]>
To: Aleksey Shipilev <[hidden email]>,
        [hidden email]
Subject: Re: [concurrency-interest] Fixed Rate Executor Service
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

Yes, so my question then is what is the use-case for rate-limiter, the
limiter of ingress of requests into the pool. Also, I suppose that when
the limit is reached, the requests.....ermmm.... wait somewhere in a
queue? So is the purpose of rate limiter to control contention on the
executor thread pool /task queue/?


Alex


On 04/02/2015 12:16, Aleksey Shipilev wrote:
> Um... Because that's a one-sided rate limiter, not a two-sided
> "semaphore" guarding a section. As far as I can see, OP does not talk
> about limiting the number of concurrent tasks (that translates to
> limiting the resources used at a given time).
>
> -Aleksey.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency-interest Digest, Vol 121, Issue 8

oleksandr otenko
On 04/02/2015 15:53, Valentin Kovalenko wrote:
>>is the purpose of rate limiter to control contention on the
executor thread pool /task queue/?
The purpose of fixed rate executor is exactly the following: to fire actions at the specified rate (not with higher rate, not with lower rate).

>>when the limit is reached, the requests.....ermmm.... wait somewhere in a
queue?
When the limit is reached, executor becomes idle till the start of next period.
Could you explain what do you mean by "requests?" I don't understand because there are no requests, there is only executor that fires actions (calls action.run()) and ensures that at each period not more that RATE actions were completed.

ok, actions then.

You need to explain the meaning of "action". Because I expect the actions last for some time, do you count the action for the duration of the action, or you only count the start of action. If you count the action for the whole duration of the actions, then there is no meaning in "per second", because you really are looking at the number of actions "in flight". If you only count the starts of actions, then depending on the granularity an the action duration you will get some spread of the number of actions really "in flight". I am wondering about the use case for this second interpretation, if that's what is meant.

Alex




Date: Wed, 04 Feb 2015 12:55:53 +0000
From: Oleksandr Otenko <[hidden email]>
To: Aleksey Shipilev <[hidden email]>,
        [hidden email]
Subject: Re: [concurrency-interest] Fixed Rate Executor Service
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

Yes, so my question then is what is the use-case for rate-limiter, the
limiter of ingress of requests into the pool. Also, I suppose that when
the limit is reached, the requests.....ermmm.... wait somewhere in a
queue? So is the purpose of rate limiter to control contention on the
executor thread pool /task queue/?


Alex


On 04/02/2015 12:16, Aleksey Shipilev wrote:
> Um... Because that's a one-sided rate limiter, not a two-sided
> "semaphore" guarding a section. As far as I can see, OP does not talk
> about limiting the number of concurrent tasks (that translates to
> limiting the resources used at a given time).
>
> -Aleksey.


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency-interest Digest, Vol 121, Issue 8

Valentin Kovalenko
>>the actions last for some time
yes

>>do you count the action for the duration of the action, or you only count the start of action
My bad. FixedRateExecutor must start (fire) RATE actions per period and must ensure that all actions started during a period were completed during the same period. If any of these requirements are violated, it must precess the situation by using FailedRatePolicy. Does it make sense for you?

On Wed, Feb 4, 2015 at 8:04 PM, Oleksandr Otenko <[hidden email]> wrote:
On 04/02/2015 15:53, Valentin Kovalenko wrote:
>>is the purpose of rate limiter to control contention on the
executor thread pool /task queue/?
The purpose of fixed rate executor is exactly the following: to fire actions at the specified rate (not with higher rate, not with lower rate).

>>when the limit is reached, the requests.....ermmm.... wait somewhere in a
queue?
When the limit is reached, executor becomes idle till the start of next period.
Could you explain what do you mean by "requests?" I don't understand because there are no requests, there is only executor that fires actions (calls action.run()) and ensures that at each period not more that RATE actions were completed.

ok, actions then.

You need to explain the meaning of "action". Because I expect the actions last for some time, do you count the action for the duration of the action, or you only count the start of action. If you count the action for the whole duration of the actions, then there is no meaning in "per second", because you really are looking at the number of actions "in flight". If you only count the starts of actions, then depending on the granularity an the action duration you will get some spread of the number of actions really "in flight". I am wondering about the use case for this second interpretation, if that's what is meant.

Alex

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency-interest Digest, Vol 121, Issue 8

oleksandr otenko
It seems most of this is covered by a plain Semaphore: if the next permit is not available, the rate has failed.

Alex

On 04/02/2015 17:23, Valentin Kovalenko wrote:
>>the actions last for some time
yes

>>do you count the action for the duration of the action, or you only count the start of action
My bad. FixedRateExecutor must start (fire) RATE actions per period and must ensure that all actions started during a period were completed during the same period. If any of these requirements are violated, it must precess the situation by using FailedRatePolicy. Does it make sense for you?

On Wed, Feb 4, 2015 at 8:04 PM, Oleksandr Otenko <[hidden email]> wrote:
On 04/02/2015 15:53, Valentin Kovalenko wrote:
>>is the purpose of rate limiter to control contention on the
executor thread pool /task queue/?
The purpose of fixed rate executor is exactly the following: to fire actions at the specified rate (not with higher rate, not with lower rate).

>>when the limit is reached, the requests.....ermmm.... wait somewhere in a
queue?
When the limit is reached, executor becomes idle till the start of next period.
Could you explain what do you mean by "requests?" I don't understand because there are no requests, there is only executor that fires actions (calls action.run()) and ensures that at each period not more that RATE actions were completed.

ok, actions then.

You need to explain the meaning of "action". Because I expect the actions last for some time, do you count the action for the duration of the action, or you only count the start of action. If you count the action for the whole duration of the actions, then there is no meaning in "per second", because you really are looking at the number of actions "in flight". If you only count the starts of actions, then depending on the granularity an the action duration you will get some spread of the number of actions really "in flight". I am wondering about the use case for this second interpretation, if that's what is meant.

Alex


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest