Name: sidekiq-status
Owner: Harvest
Description: an extension to the sidekiq message processing to track your jobs
Created: 2015-06-23 07:01:18.0
Updated: 2015-09-13 02:21:40.0
Pushed: 2015-06-29 13:48:15.0
Homepage: null
Size: 184
Language: Ruby
GitHub Committers
User | Most Recent Commit | # Commits |
---|
Other Committers
User | Most Recent Commit | # Commits |
---|
An extension to Sidekiq message processing to track your jobs. Inspired by resque-status and mostly copying its features, using Sidekiq's middleware.
gem install sidekiq-status
Configure your middleware chains, lookup Middleware usage on Sidekiq wiki for more info.
ire 'sidekiq'
ire 'sidekiq-status'
kiq.configure_client do |config|
nfig.client_middleware do |chain|
chain.add Sidekiq::Status::ClientMiddleware
d
kiq.configure_server do |config|
nfig.server_middleware do |chain|
chain.add Sidekiq::Status::ServerMiddleware, expiration: 30.minutes # default
d
nfig.client_middleware do |chain|
chain.add Sidekiq::Status::ClientMiddleware
d
After that you can use your jobs as usual and only include Sidekiq::Status::Worker
module if you want additional functionality of tracking progress and passing any data from job to client.
s MyJob
clude Sidekiq::Worker
f perform(*args)
your code goes here
d
To overwrite expiration on worker basis and don't use global expiration for all workers write a expiration method like this below:
s MyJob
clude Sidekiq::Worker
f expiration
@expiration ||= 60*60*24*30 # 30 days
d
f perform(*args)
# your code goes here
d
But keep in mind that such thing will store details of job as long as expiration is set, so it may charm your Redis storage/memory consumption. Because Redis stores all data in RAM.
Query for job status any time later:
id = MyJob.perform_async(*args)
ueued, :working, :complete or :failed , nil after expiry (30 minutes)
us = Sidekiq::Status::status(job_id)
kiq::Status::queued? job_id
kiq::Status::working? job_id
kiq::Status::complete? job_id
kiq::Status::failed? job_id
s MyJob
clude Sidekiq::Worker
clude Sidekiq::Status::Worker # Important!
f perform(*args)
# your code goes here
# the common idiom to track progress of your task
total 100 # by default
at 5, "Almost done"
# a way to associate data with your job
store vino: 'veritas'
# a way of retrieving said data
# remember that retrieved data is always is String|nil
vino = retrieve :vino
d
id = MyJob.perform_async(*args)
= Sidekiq::Status::get_all job_id
# => {status: 'complete', update_time: 1360006573, vino: 'veritas'}
kiq::Status::get job_id, :vino #=> 'veritas'
kiq::Status::at job_id #=> 5
kiq::Status::total job_id #=> 100
kiq::Status::message job_id #=> "Almost done"
kiq::Status::pct_complete job_id #=> 5
duled_job_id = MyJob.perform_in 3600
kiq::Status.cancel scheduled_job_id #=> true
sn't cancel running jobs, this is more like unscheduling, therefore an alias:
kiq::Status.unschedule scheduled_job_id #=> true
Sidekiq::Status also provides an extension to Sidekiq web interface with a /statuses
page.
Setup Sidekiq web interface according to Sidekiq documentation and add the Sidekiq::Status::Web require:
ire 'sidekiq/web'
ire 'sidekiq-status/web'
Drawing analogy from sidekiq testing by inlining,
sidekiq-status
allows to bypass redis and return a stubbed :complete
status.
Since inlining your sidekiq worker will run it in-process, any exception it throws will make your test fail.
It will also run synchronously, so by the time you get to query the job status, the job will have been completed
successfully.
In other words, you'll get the :complete
status only if the job didn't fail.
Inlining example:
You can run Sidekiq workers inline in your tests by requiring the sidekiq/testing/inline
file in your {test,spec}_helper.rb
:
require 'sidekiq/testing/inline'
To use sidekiq-status
inlining, require it too in your {test,spec}_helper.rb
:
require 'sidekiq-status/testing/inline'
MIT License , see LICENSE for more details. © 2012 - 2015 Evgeniy Tsvigun