usleep used intentionally?
ApoorvSaxena opened this issue · comments
Any specific reason for using usleep in the throttle method https://github.com/davedevelopment/stiphle/blob/master/src/Stiphle/Throttle/LeakyBucket.php#L62 ?
To allow sub-second sleep times?
Do you intend to make the request wait before serving response to the request, if it has crossed the limit?
The option is there, I usually use the getEstimate method and return a 409 response
Application logic residing in the library code does not seem good. What do you say about removing this piece of code from the throttle method's body?
Should I submit a pull request regarding the same?
And replacing it with what?
On 12 December 2014 at 08:55, Apoorv Saxena notifications@github.com
wrote:
Application logic residing in the library code does not seem good. What do
you say about removing this piece of code from the throttle method's body?—
Reply to this email directly or view it on GitHub
#2 (comment)
.
I only intend to remove usleep, also throttle method should ideally be used after calling the getEstimate method in the application code.
I don't really see what the point would be, except relaxing the throttle.
Consider a throttle that should allow one request per hour. Now, 5 threads, all calling getEstimate at the same time. Each would be told an estimate of 5 seconds, so the threads each sleep themselves for 5 seconds, then call the throttle method. Because the throttle method doesn't do any actual throttling, all 5 requests go on to acquire a lock, record a request and release the lock, rendering the throttling useless.
I assume the implementation of locks to prevent the lock from being distributed to multiple requests. Also, how do you ascertain that every thread in your example gets a different wait time before catching a lock for themselves?
The lock is on the storage, to prevent multiple threads updating the request count at the same time.
Also, how do you ascertain that every thread in your example gets a different wait time before catching a lock for themselves?
Not sure I understand that part?
Still not sure though about how adding a wait to requests completely eliminates the issue of concurrent requests hit.
It doesn't completely eliminate it, but I think it's much better than leaving it to the userland code.