Skip to content
Joe Marty edited this page Dec 30, 2020 · 6 revisions

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.

Timeouts

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')

Job Handling Strategies

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

Handling Jobs

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.