-
Notifications
You must be signed in to change notification settings - Fork 332
Failures
Background processing calls for special treatment for failures.
- A background job should have limits. Limited resources, limited time, etc.
- A background job should be able to be: retried, dismissed, acknowledged, rejected.
Sneakers handles this in the following ways.
Built-in timeout functionality was removed in version 2.10 (see #354)
In previous versions, you can set a job timeout like this:
Sneakers-wide:
Sneakers.configure :timeout_job_after => 1
Worker-wide:
class ProfilingWorker
include Sneakers::Worker
from_queue 'downloads',
:ack => true,
:timeout_job_after => 1
...
In newer versions, you can just use ruby's Timeout::timeout to raise your own timeout error! (don't forget to require 'timeout'
)
When a job needs handling, a Sneakers Handler should do the job. The default one is called a Oneshot
handler, because it only tries once.
A handler conforms to:
- Job is done -
#acknowledge
- Job failed (by design) -
#reject
- Job failed (exceptional error) -
#error
(Versions prior to 2.10 also included special handling of timeouts as #timeout
)
And the default Oneshot handler does nothing fancy:
-
#acknowledge
: acknowledges the message -
#reject
: rejects the message (without requeuing, by default) -
#error
: rejects the message (without requeuing, by default)
You can implement your own handler (how about ExponentialRetry
?) by filling out the interface and plugging it via configuration like this:
require 'mylib/handlers/exponential_retry'
Sneakers.configure :handler => ExponentialRetry
Within your #work
method, you can actually handle job control by just calling #ack!
, #requeue!
or #reject!
.
Raising an exception within a worker will call #error
internally, and then re-raise the exception so it bubbles up to your top-level (or intermediate) exception handler.