* Prepare for upcoming Sidekiq::Config redesign
Adjust the server internals to use a config object rather than refering directly to the Sidekiq module.
* Add a compatibility layer for `redis-client`
As discussed in https://github.com/mperham/sidekiq/pull/5253
Switching entirely to redis-client is deemed risky, so instead
we can support both.
All is needed is a small translation layer, and some very minimal
adjustments in the callers.
Co-authored-by: Jean Boussier <jean.boussier@gmail.com>
Co-authored-by: Mike Perham <mperham@gmail.com>
When there are scheduled jobs that are due, the scheduler thread will
keep going instead of waiting for the next poll.
Co-authored-by: Heinrich Lee Yu <heinrich@gitlab.com>
* Refactor CLI test
Extracted 3 main parts:
- parse
- run
- signal handling
* Move demonization and pid write from parse to run phase
* Move queues default from validate to setup options phase
* Add pry-byebug gem
* Drop Sidekiq::Test
* Require launcher in CLI
* Remove TODOs
When pushing a job, the middleware should be able to access the Redis instance associated with that job. Previously, Sidekiq was limited to one global Redis instance. Now that we want to support sharding, we have to explicitly pass the instance in OR hack up APIs with thread local variables. Explicit is better.
