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

(BL)POP considered dangerous #93

Closed
dmag opened this issue May 18, 2010 · 1 comment
Closed

(BL)POP considered dangerous #93

dmag opened this issue May 18, 2010 · 1 comment

Comments

@dmag
Copy link

dmag commented May 18, 2010

There's a pretty big window of opportunity for failure after the (BL)POP, but before processing is completely finished. Any problem and the job will be lost forever. (Problems could be kill -9, power loss, out of memory during fork, kernel OOM killer, etc.)

Redis has the RPOPLPUSH command to fix this exact problem (but it requires a bit more complexity, such as per-worker queues or other timeout mechanism). See "Programming patterns: safe queues"
http://code.google.com/p/redis/wiki/RpoplpushCommand

I guess the big question is: Should safety be a first class property of Resque, or should it be relegated to a plug-in? (At the very least, this issue should be documented in the meantime).

@defunkt
Copy link
Contributor

defunkt commented May 18, 2010

Resque does not advertise itself as a system that will never lose your jobs. Part of the design is we don't care if jobs are lost.

If this is important to you, there are plenty of systems which can offer that feature.

Also: as long as your machine doesn't go away forever (e.g. EC2 instance), Resque won't lose jobs due to kill -9, power loss, out of memory during fork, kernel OOM killer.

This issue was closed.
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