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

Automatic unlock of jobs #362

Closed
Laykou opened this issue Jan 5, 2019 · 2 comments
Closed

Automatic unlock of jobs #362

Laykou opened this issue Jan 5, 2019 · 2 comments

Comments

@Laykou
Copy link

Laykou commented Jan 5, 2019

Is your feature request related to a problem? Please describe.
When sidekiq process is killed (SIGKILL) everything stays as-is in Redis. Sidekiq has mechanism of heartbeats to check if processor is still running or not. The same should apply for the unique jobs.

Describe the solution you'd like
I suggest some job that would periodically (e.g. every minute) check whether the unique digest lock is still valid = whether it is assigned to some running job. This would require to store also "JID" to each unique digest so that they can be paired together.

If the job is not running anymore it means the unique digest is stale and should be removed.

Otherwise it is blocking all future jobs until manual removal. I would like to prevent this manual removals by implementing this "auto-heal" feature.

@mhenrixon
Copy link
Owner

This has been discussed to death (pun intended). There is absolutely nothing the gem can or should do about this. If the job is back in redis it should still be considered unique because it will be retried.

@mhenrixon
Copy link
Owner

If you feel like having a scheduled job to clear out jobs it is all on you :) I might create a better functionality for finding and clearing such jobs manually in the future but there needs to be manual intervention here. This is what Mike Perham does with the pro and enterprise versions of sidekiq.

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

No branches or pull requests

2 participants