diff options
Diffstat (limited to 'doc/development/sidekiq/limited_capacity_worker.md')
-rw-r--r-- | doc/development/sidekiq/limited_capacity_worker.md | 22 |
1 files changed, 17 insertions, 5 deletions
diff --git a/doc/development/sidekiq/limited_capacity_worker.md b/doc/development/sidekiq/limited_capacity_worker.md index 5efb9b16725..b1aff829d4d 100644 --- a/doc/development/sidekiq/limited_capacity_worker.md +++ b/doc/development/sidekiq/limited_capacity_worker.md @@ -34,17 +34,29 @@ class MyDummyWorker end ``` -Additional to the regular worker, a cron worker must be defined as well to -backfill the queue with jobs. the arguments passed to `perform_with_capacity` -are passed to the `perform_work` method. +To queue this worker, use +`MyDummyWorker.perform_with_capacity(*args)`. The `*args` passed to this worker +are passed to the `perform_work` method. Due to the way this job throttles +and requeues itself, it is expected that you always provide the same +`*args` in every usage. In practice, this type of worker is often not +used with arguments and must instead consume a workload stored +elsewhere (like in PostgreSQL). This design also means it is unsuitable to +take a normal Sidekiq workload with arguments and make it a +`LimitedCapacity::Worker`. Instead, to use this, you might need to +re-architect your queue to be stored elsewhere. + +A common use case for this kind of worker is one that runs periodically +consuming a separate queue of work to be done (like from PostgreSQL). In that case, +you need an additional cron worker to start the worker periodically. For +example, in the following scheduler: ```ruby class ScheduleMyDummyCronWorker include ApplicationWorker include CronjobQueue - def perform(*args) - MyDummyWorker.perform_with_capacity(*args) + def perform + MyDummyWorker.perform_with_capacity end end ``` |