Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
G
gitlab-ce
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
1
Merge Requests
1
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
nexedi
gitlab-ce
Commits
0ec81dd5
Commit
0ec81dd5
authored
Dec 12, 2017
by
Douwe Maan
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Update docs
parent
b1849ee2
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
44 additions
and
15 deletions
+44
-15
doc/development/sidekiq_style_guide.md
doc/development/sidekiq_style_guide.md
+44
-15
No files found.
doc/development/sidekiq_style_guide.md
View file @
0ec81dd5
...
@@ -9,25 +9,54 @@ All workers should include `ApplicationWorker` instead of `Sidekiq::Worker`,
...
@@ -9,25 +9,54 @@ All workers should include `ApplicationWorker` instead of `Sidekiq::Worker`,
which adds some convenience methods and automatically sets the queue based on
which adds some convenience methods and automatically sets the queue based on
the worker's name.
the worker's name.
## De
fault Queue
## De
dicated Queues
Use of the "default" queue is not allowed. Every worker should use a queue that
All workers should use their own queue, which is automatically set based on the
matches the worker's purpose the closest. For example, workers that are to be
worker class name. For a worker named
`ProcessSomethingWorker`
, the queue name
executed periodically should use the "cronjob" queue.
would be
`process_something`
. If you're not sure what queue a worker uses,
you can find it using
`SomeWorker.queue`
. There is almost never a reason to
manually override the queue name using
`sidekiq_options queue: :some_queue`
.
A list of all available queues can be found in
`config/sidekiq_queues.yml`
.
## Queue Namespaces
## Dedicated Queues
While different workers cannot share a queue, they can share a queue namespace.
Most workers should use their own queue, which is automatically set based on the
Defining a queue namespace for a worker makes it possible to start a Sidekiq
worker class name. For a worker named
`ProcessSomethingWorker`
, the queue name
process that automatically handles jobs for all workers in that namespace,
would be
`process_something`
. If you're not sure what a worker's queue name is,
without needing to explicitly list all their queue names. If, for example, all
you can find it using
`SomeWorker.queue`
.
workers that are managed by sidekiq-cron use the
`cronjob`
queue namespace, we
can spin up a Sidekiq process specifically for these kinds of scheduled jobs.
If a new worker using the
`cronjob`
namespace is added later on, the Sidekiq
process will automatically pick up jobs for that worker too (after having been
restarted), without the need to change any configuration.
A queue namespace can be set using the
`queue_namespace`
DSL class method:
```
ruby
class
SomeScheduledTaskWorker
include
ApplicationWorker
queue_namespace
:cronjob
# ...
end
```
Behind the scenes, this will set
`SomeScheduledTaskWorker.queue`
to
`cronjob:some_scheduled_task`
. Commonly used namespaces will have their own
concern module that can easily be included into the worker class, and that may
set other Sidekiq options besides the queue namespace.
`CronjobQueue`
, for
example, sets the namespace, but also disables retries.
`bundle exec sidekiq`
is namespace-aware, and will automatically listen on all
queues in a namespace (technically: all queues prefixed with the namespace name)
when a namespace is provided instead of a simple queue name in the
`--queue`
(
`-q`
) option, or in the
`:queues:`
section in
`config/sidekiq_queues.yml`
.
In some cases multiple workers do use the same queue. For example, the variou
s
Note that adding a worker to an existing namespace should be done with care, a
s
workers for updating CI pipelines all use the
`pipeline`
queue. Adding workers
the extra jobs will take resources away from jobs from workers that were already
t
o existing queues should be done with care, as adding more workers can lead to
t
here, if the resources available to the Sidekiq process handling the namespace
slow jobs blocking work (even for different jobs) on the shared queue
.
are not adjusted appropriately
.
## Tests
## Tests
...
@@ -36,7 +65,7 @@ tests should be placed in `spec/workers`.
...
@@ -36,7 +65,7 @@ tests should be placed in `spec/workers`.
## Removing or renaming queues
## Removing or renaming queues
Try to avoid renaming or removing queues in minor and patch releases.
Try to avoid renaming or removing
workers and their
queues in minor and patch releases.
During online update instance can have pending jobs and removing the queue can
During online update instance can have pending jobs and removing the queue can
lead to those jobs being stuck forever. If you can't write migration for those
lead to those jobs being stuck forever. If you can't write migration for those
Sidekiq jobs, please consider doing rename or remove queue in major release only.
Sidekiq jobs, please consider doing rename or remove queue in major release only.
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment