README.md

Clockwork - a clock process to replace cron

Cron is non-ideal for running scheduled application tasks, especially in an app
deployed to multiple machines. More details.

Clockwork is a cron replacement. It runs as a lightweight, long-running Ruby
process which sits alongside your web processes (Mongrel/Thin) and your worker
processes (DJ/Resque/Minion/Stalker) to schedule recurring work at particular
times or dates. For example, refreshing feeds on an hourly basis, or send
reminder emails on a nightly basis, or generating invoices once a month on the
1st.

Use with queueing

The clock process only makes sense as a place to schedule work to be done, not
to do the work. It avoids locking by running as a single process, but this
makes it impossible to parallelize. For doing the work, you should be using a
job queueing system, such as
Delayed Job,
Beanstalk/Stalker,
RabbitMQ/Minion, or
Resque. This design allows a
simple clock process with no locks, but also offers near infinite horizontal
scalability.

Using a queueing system which doesn't require that your full application be
loaded is preferable, because the clock process can keep a tiny memory
footprint. If you're using DJ or Resque, however, you can go ahead and load
your full application enviroment, and use per-event blocks to call DJ or Resque
enqueue methods. For example, with DJ/Rails:

Anatomy of a clock file

clock.rb is standard Ruby. Since we include the Clockwork module (the
clockwork binary does this automatically, or you can do it explicitly), this
exposes a small DSL ("handler" and "every") to define the handler for events,
and then the events themselves.

The handler typically looks like this:

handler { |job| enqueue_your_job(job) }

This block will be invoked every time an event is triggered, with the job name
passed in. In most cases, you should be able to pass the job name directly
through to your queueing system.

The second part of the file are the events, which roughly resembles a crontab:

every(5.minutes, 'thing.do')
every(1.hour, 'otherthing.do')

In the first line of this example, an event will be triggered once every five
minutes, passing the job name 'thing.do' into the handler. The handler shown
above would thus call enqueue_your_job('thing.do').

You can also pass a custom block to the handler, for job queueing systems that
rely on classes rather than job names (i.e. DJ and Resque). In this case, you
need not define a general event handler, and instead provide one with each
event:

every(5.minutes, 'thing.do') { Thing.send_later(:do) }

If you provide a custom handler for the block, the job name is used only for
logging.

In production

Only one clock process should ever be running across your whole application
deployment. For example, if your app is running on three VPS machines (two app
servers and one database), your app machines might have the following process
topography: