Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sidekiq: setup db storage #1955

Open
vohmar opened this issue Apr 27, 2021 · 2 comments
Open

Sidekiq: setup db storage #1955

vohmar opened this issue Apr 27, 2021 · 2 comments

Comments

@vohmar
Copy link
Contributor

vohmar commented Apr 27, 2021

Sidekiq runs on in-memory redis database. As we have scheduled tasks that are planned for days ahead we need a solution to preserve the tasks so that redis server restart would not wipe the list clean.

Implement storage layer for storing tasks scheduled to run and possibly load jobs to redis memory only if the task is planned to run within 24 hrs

Related to: #1954

@yulgolem
Copy link
Contributor

yulgolem commented Apr 27, 2021

Looks like we don't need to.

According to Sidekiq documentation

By default, Sidekiq 6+ gives workers 25 seconds to shut down. (Run Sidekiq <6 with -t 25.) This is carefully chosen because Heroku and AWS ECS give a process 30 seconds to shutdown before killing it. After 25 seconds, any remaining jobs still in progress are pushed back onto Redis so they can be immediately restarted when Sidekiq starts back up. Remember that Sidekiq will run your jobs AT LEAST once so they need to be idempotent. This is one example of how a job can be run twice.

Tried that on staging - scheduled manually an whois update job one week ahead, restarted Redis service from shell console, redeployed application as a whole. Job persists as a scheduled.

@yulgolem
Copy link
Contributor

As well I suppose we should implement some Redis-side persistence mechanisms as per https://redis.io/topics/persistence

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants