Allow setting custom behavior when rate limit exceeded #16
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
You can now pass a proc in to ann exceeded option to the throttler options. If this is passed in, then the default behavior (which is to perform_in(delay) will be used instead. The proc that is passed in is instance_exec'd which gives access to all the rate limiters variables. This is probably not that safe...
The behavior can be specified with the :exceeded property in throttler options for the class. By leaving this nil or setting it to :retry, the previous behavior of retrying the job occurrs. To specify different behavior, set the :exceeded option to a Proc that takes up to 4 arguments: 1) The period/delay of the rate limiter 2) The worker object that is processing the job. 3) The payload (job arguments) 4) The queue the job came from. A lambda can also be used if all 4 of the above arguments are specified in the lambda definition.
lucasprag
approved these changes
Feb 15, 2019
| @@ -302,7 +302,9 @@ | |||
|
|
|||
| it 'calls the exceeded callback with the configured #period' do | |||
| callback = Proc.new {} | |||
| expect(callback).to receive(:call).with(rate_limit.period) | |||
| #expect(callback).to receive(:call).with(rate_limit.period) | |||
|
+1 would love to see this merged |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While rescheduling a job to occur later might be desirable for many situations, there are others where it's not.
For example, I have a job that is rate limited on a per-worker machine basis.
E.g., each machine is only allowed to process 1,000 jobs an hour, however I still want to process jobs as fast as possible.
Thus, I want to immediately add throttled jobs back to the job queue to allow another machine (which hasn't exceeded its threshold) to process it.
NB1: There is obviously a race condition in this example, but in practice it ensures that jobs are retried immediately, independent of the rate limit period, which is important for my use case. Note that a race condition also exists with the existing behavior (I think) because the job is being retried after a static period. Let's say that a job is limited to 1,000 executions per hour. 1 job was executed at :00 while another 1,000 were executed at :59. This will result in one of the jobs queued at :59 being retried in 60 minutes. If this pattern (1 job at :00, 1,000 at :59) continues ad infinitum, some throttled jobs might never be processed (or processed WAYYYYYYYY after they were submitted). At least I think that's how it would work...
To execute non-default behavior, simply specify a proc that takes up to 4 arguments (the period/delay of the rate limiter, the worker that's executing the job, the message payload, and the queue the job came from) in the :exceeded key in the worker class's throttler options.
NB2: The rate limiter now always passes these arguments to the specified exceeded block, so, while you can use a lambda instead of a proc, if you do so the lambda has to accept all 4 parameters. At least I think it does :)