resque 0.2.0
Sign up to get free protection for your applications and to get access to all the features.
Potentially problematic release.
This version of resque might be problematic. Click here for more details.
- data/.kick +26 -0
- data/HISTORY.md +3 -0
- data/LICENSE +20 -0
- data/README.markdown +638 -0
- data/Rakefile +61 -0
- data/TODO.md +60 -0
- data/bin/resque +57 -0
- data/bin/resque-web +47 -0
- data/config.ru +8 -0
- data/deps.rip +5 -0
- data/examples/async_helper.rb +31 -0
- data/examples/demo/README.markdown +71 -0
- data/examples/demo/Rakefile +3 -0
- data/examples/demo/app.rb +27 -0
- data/examples/demo/config.ru +19 -0
- data/examples/demo/job.rb +12 -0
- data/examples/existing_classes_as_jobs.rb +3 -0
- data/examples/instance.rb +11 -0
- data/examples/simple.rb +30 -0
- data/init.rb +1 -0
- data/lib/resque.rb +184 -0
- data/lib/resque/errors.rb +7 -0
- data/lib/resque/failure.rb +57 -0
- data/lib/resque/failure/base.rb +54 -0
- data/lib/resque/failure/hoptoad.rb +88 -0
- data/lib/resque/failure/redis.rb +28 -0
- data/lib/resque/helpers.rb +57 -0
- data/lib/resque/job.rb +91 -0
- data/lib/resque/server.rb +154 -0
- data/lib/resque/server/public/idle.png +0 -0
- data/lib/resque/server/public/jquery-1.3.2.min.js +19 -0
- data/lib/resque/server/public/jquery.relatize_date.js +95 -0
- data/lib/resque/server/public/nav-bg.png +0 -0
- data/lib/resque/server/public/ranger.js +7 -0
- data/lib/resque/server/public/reset.css +51 -0
- data/lib/resque/server/public/style.css +67 -0
- data/lib/resque/server/public/tab_b.gif +0 -0
- data/lib/resque/server/public/tab_r.gif +0 -0
- data/lib/resque/server/public/tabs.css +189 -0
- data/lib/resque/server/public/working.png +0 -0
- data/lib/resque/server/views/error.erb +1 -0
- data/lib/resque/server/views/failed.erb +29 -0
- data/lib/resque/server/views/key.erb +17 -0
- data/lib/resque/server/views/layout.erb +43 -0
- data/lib/resque/server/views/next_more.erb +12 -0
- data/lib/resque/server/views/overview.erb +2 -0
- data/lib/resque/server/views/queues.erb +40 -0
- data/lib/resque/server/views/stats.erb +62 -0
- data/lib/resque/server/views/workers.erb +72 -0
- data/lib/resque/server/views/working.erb +66 -0
- data/lib/resque/stat.rb +53 -0
- data/lib/resque/tasks.rb +24 -0
- data/lib/resque/version.rb +3 -0
- data/lib/resque/worker.rb +406 -0
- data/tasks/redis.rake +125 -0
- data/tasks/resque.rake +2 -0
- data/test/redis-test.conf +132 -0
- data/test/resque_test.rb +160 -0
- data/test/test_helper.rb +90 -0
- data/test/worker_test.rb +212 -0
- metadata +124 -0
data/.kick
ADDED
@@ -0,0 +1,26 @@
|
|
1
|
+
# take control of the growl notifications
|
2
|
+
module GrowlHacks
|
3
|
+
def growl(type, subject, body, *args, &block)
|
4
|
+
case type
|
5
|
+
when Kicker::GROWL_NOTIFICATIONS[:succeeded]
|
6
|
+
puts subject = "Success"
|
7
|
+
body = body.split("\n").last
|
8
|
+
when Kicker::GROWL_NOTIFICATIONS[:failed]
|
9
|
+
subject = "Failure"
|
10
|
+
puts body
|
11
|
+
body = body.split("\n").last
|
12
|
+
else
|
13
|
+
return nil
|
14
|
+
end
|
15
|
+
super(type, subject, body, *args, &block)
|
16
|
+
end
|
17
|
+
end
|
18
|
+
|
19
|
+
Kicker.send :extend, GrowlHacks
|
20
|
+
|
21
|
+
# no logging
|
22
|
+
Kicker::Utils.module_eval do
|
23
|
+
def log(message)
|
24
|
+
nil
|
25
|
+
end
|
26
|
+
end
|
data/HISTORY.md
ADDED
data/LICENSE
ADDED
@@ -0,0 +1,20 @@
|
|
1
|
+
Copyright (c) 2009 Chris Wanstrath
|
2
|
+
|
3
|
+
Permission is hereby granted, free of charge, to any person obtaining
|
4
|
+
a copy of this software and associated documentation files (the
|
5
|
+
"Software"), to deal in the Software without restriction, including
|
6
|
+
without limitation the rights to use, copy, modify, merge, publish,
|
7
|
+
distribute, sublicense, and/or sell copies of the Software, and to
|
8
|
+
permit persons to whom the Software is furnished to do so, subject to
|
9
|
+
the following conditions:
|
10
|
+
|
11
|
+
The above copyright notice and this permission notice shall be
|
12
|
+
included in all copies or substantial portions of the Software.
|
13
|
+
|
14
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
15
|
+
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
16
|
+
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
17
|
+
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
|
18
|
+
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
|
19
|
+
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
|
20
|
+
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
data/README.markdown
ADDED
@@ -0,0 +1,638 @@
|
|
1
|
+
Resque
|
2
|
+
======
|
3
|
+
|
4
|
+
Resque is a Redis-backed library for creating background jobs, placing
|
5
|
+
those jobs on multiple queues, and processing them later.
|
6
|
+
|
7
|
+
Background jobs can be any Ruby class or module that responds to
|
8
|
+
`perform`. Your existing classes can easily be converted to background
|
9
|
+
jobs or you can create new classes specifically to do work. Or, you
|
10
|
+
can do both.
|
11
|
+
|
12
|
+
Resque is heavily inspired by DelayedJob (which rocks) and is
|
13
|
+
comprised of three parts:
|
14
|
+
|
15
|
+
1. A Ruby library for creating, querying, and processing jobs
|
16
|
+
2. A Rake task for starting a worker which processes jobs
|
17
|
+
3. A Sinatra app for monitoring queues, jobs, and workers.
|
18
|
+
|
19
|
+
Resque workers can be distributed between multiple machines,
|
20
|
+
support priorities, are resililent to memory bloat / "leaks," are
|
21
|
+
optimized for REE (but work on MRI and JRuby), tell you what they're
|
22
|
+
doing, and expect failure.
|
23
|
+
|
24
|
+
Resque queues are persistent; support constant time, atomic push and
|
25
|
+
pop (thanks to Redis); provide visibility into their contents; and
|
26
|
+
store jobs as simple JSON packages.
|
27
|
+
|
28
|
+
The Resque frontend tells you what workers are doing, what workers are
|
29
|
+
not doing, what queues you're using, what's in those queues, provides
|
30
|
+
general usage stats, and helps you track failures.
|
31
|
+
|
32
|
+
|
33
|
+
The Blog Post
|
34
|
+
-------------
|
35
|
+
|
36
|
+
For the backstory, philosophy, and history of Resque's beginnings,
|
37
|
+
please see [the blog post][0].
|
38
|
+
|
39
|
+
|
40
|
+
Overview
|
41
|
+
--------
|
42
|
+
|
43
|
+
Resque allows you to create jobs and place them on a queue, then,
|
44
|
+
later, pull those jobs off the queue and process them.
|
45
|
+
|
46
|
+
Resque jobs are Ruby classes (or modules) which respond to the
|
47
|
+
`perform` method. Here's an example:
|
48
|
+
|
49
|
+
class Archive
|
50
|
+
@queue = :file_serve
|
51
|
+
|
52
|
+
def self.perform(repo_id, branch = 'master')
|
53
|
+
repo = Repository.find(repo_id)
|
54
|
+
repo.create_archive(branch)
|
55
|
+
end
|
56
|
+
end
|
57
|
+
|
58
|
+
The `@queue` class instance variable determines which queue `Archive`
|
59
|
+
jobs will be placed in. Queues are arbitrary and created on the fly -
|
60
|
+
you can name them whatever you want and have as many as you want.
|
61
|
+
|
62
|
+
To place an `Archive` job on the `file_serve` queue, we might add this
|
63
|
+
to our application's pre-existing `Repository` class:
|
64
|
+
|
65
|
+
class Repository
|
66
|
+
def async_create_archive(branch)
|
67
|
+
Resque.enqueue(Archive, self.id, branch)
|
68
|
+
end
|
69
|
+
end
|
70
|
+
|
71
|
+
Now when we call `repo.async_create_archive('masterbrew')` in our
|
72
|
+
application, a job will be created and placed on the `file_serve`
|
73
|
+
queue.
|
74
|
+
|
75
|
+
Later, a worker will run something like this code to process the job:
|
76
|
+
|
77
|
+
klass, args = Resque.reserve(:file_serve)
|
78
|
+
klass.perform(*args) if klass.respond_to? :perform
|
79
|
+
|
80
|
+
Which translates to:
|
81
|
+
|
82
|
+
Archive.perform(44, 'masterbrew')
|
83
|
+
|
84
|
+
Let's start a worker to run `file_serve` jobs:
|
85
|
+
|
86
|
+
$ cd app_root
|
87
|
+
$ QUEUE=file_serve rake resque:work
|
88
|
+
|
89
|
+
This starts one Resque worker and tells it to work off the
|
90
|
+
`file_serve` queue. As soon as it's ready it'll try to run the
|
91
|
+
`Resque.reserve` code snippet above and process jobs until it can't
|
92
|
+
find any more, at which point it will sleep for a small period and
|
93
|
+
repeatedly poll the queue for more jobs.
|
94
|
+
|
95
|
+
Workers can be given multiple queues (a "queue list") and run on
|
96
|
+
multiple machines. In fact they can be run anywhere with network
|
97
|
+
access to the Redis server.
|
98
|
+
|
99
|
+
|
100
|
+
Jobs
|
101
|
+
----
|
102
|
+
|
103
|
+
What should you run in the background? Anything that takes any time at
|
104
|
+
all. Slow INSERT statements, disk manipulating, data processing, etc.
|
105
|
+
|
106
|
+
At GitHub we use Resque to process the following types of jobs:
|
107
|
+
|
108
|
+
* Warming caches
|
109
|
+
* Counting disk usage
|
110
|
+
* Building tarballs
|
111
|
+
* Building Rubygems
|
112
|
+
* Firing off web hooks
|
113
|
+
* Creating events in the db and pre-caching them
|
114
|
+
* Building graphs
|
115
|
+
* Deleting users
|
116
|
+
* Updating our search index
|
117
|
+
|
118
|
+
As of writing we have about 35 different types of background jobs.
|
119
|
+
|
120
|
+
Keep in mind that you don't need a web app to use Resque - we just
|
121
|
+
mention "foreground" and "background" because they make conceptual
|
122
|
+
sense. You could easily be spidering sites and sticking data which
|
123
|
+
needs to be crunched later into a queue.
|
124
|
+
|
125
|
+
|
126
|
+
### Persistence
|
127
|
+
|
128
|
+
Jobs are persisted to queues as JSON objects. Let's take our `Archive`
|
129
|
+
example from above. We'll run the following code to create a job:
|
130
|
+
|
131
|
+
repo = Repository.find(44)
|
132
|
+
repo.async_create_archive('masterbrew')
|
133
|
+
|
134
|
+
The following JSON will be stored in the `file_serve` queue:
|
135
|
+
|
136
|
+
{
|
137
|
+
'class': 'Archive',
|
138
|
+
'args': [ 44, 'masterbrew' ]
|
139
|
+
}
|
140
|
+
|
141
|
+
Because of this your jobs must only accept arguments that can be JSON encoded.
|
142
|
+
|
143
|
+
So instead of doing this:
|
144
|
+
|
145
|
+
Resque.enqueue(Archive, self, branch)
|
146
|
+
|
147
|
+
do this:
|
148
|
+
|
149
|
+
Resque.enqueue(Archive, self.id, branch)
|
150
|
+
|
151
|
+
This is why our above example (and all the examples in `examples/`)
|
152
|
+
uses object IDs instead of passing around the objects.
|
153
|
+
|
154
|
+
While this is less convenient than just sticking a marshalled object
|
155
|
+
in the database, it gives you a slight advantage: your jobs will be
|
156
|
+
run against the most recent version of an object because they need to
|
157
|
+
pull from the DB or cache.
|
158
|
+
|
159
|
+
If your jobs were run against marshalled objects, they could
|
160
|
+
potentially be operating on a stale record with out-of-date information.
|
161
|
+
|
162
|
+
|
163
|
+
### send_later / async
|
164
|
+
|
165
|
+
Want something like DelayedJob's `send_later` or the ability to use
|
166
|
+
instance methods instead of just methods for jobs? See the `examples/`
|
167
|
+
directory for goodies.
|
168
|
+
|
169
|
+
We plan to provide first class `async` support in a future release.
|
170
|
+
|
171
|
+
|
172
|
+
### Failure
|
173
|
+
|
174
|
+
If a job raises an exception, it is logged and handed off to the
|
175
|
+
`Resque::Failure` module. Failures are logged either locally in Redis
|
176
|
+
or using some different backend.
|
177
|
+
|
178
|
+
For example, Resque ships with Hoptoad support.
|
179
|
+
|
180
|
+
Keep this in mind when writing your jobs: you may want to throw
|
181
|
+
exceptions you would not normally throw in order to assist debugging.
|
182
|
+
|
183
|
+
|
184
|
+
Workers
|
185
|
+
-------
|
186
|
+
|
187
|
+
Resque workers are rake tasks the run forever. They basically do this:
|
188
|
+
|
189
|
+
start
|
190
|
+
loop do
|
191
|
+
if job = reserve
|
192
|
+
job.process
|
193
|
+
else
|
194
|
+
sleep 5
|
195
|
+
end
|
196
|
+
end
|
197
|
+
shutdown
|
198
|
+
|
199
|
+
Starting a worker is simple. Here's our example from earlier:
|
200
|
+
|
201
|
+
$ QUEUE=file_serve rake resque:work
|
202
|
+
|
203
|
+
By default Resque won't know about your application's
|
204
|
+
environment. That is, it won't be able to find and run your jobs - it
|
205
|
+
needs to load your application into memory.
|
206
|
+
|
207
|
+
If we've installed Resque as a Rails plugin, we might run this command
|
208
|
+
from our RAILS_ROOT:
|
209
|
+
|
210
|
+
$ QUEUE=file_serve rake environment resque:work
|
211
|
+
|
212
|
+
This will load the environment before starting a worker. Alternately
|
213
|
+
we can define a `resque:setup` task with a dependency on the
|
214
|
+
`environment` rake task:
|
215
|
+
|
216
|
+
task "resque:setup" => :environment
|
217
|
+
|
218
|
+
GitHub's setup task looks like this:
|
219
|
+
|
220
|
+
task "resque:setup" => :environment do
|
221
|
+
Grit::Git.git_timeout = 10.minutes
|
222
|
+
end
|
223
|
+
|
224
|
+
We don't want the `git_timeout` as high as 10 minutes in our web app,
|
225
|
+
but in the Resque workers it's fine.
|
226
|
+
|
227
|
+
|
228
|
+
## Logging
|
229
|
+
|
230
|
+
Workers support basic logging to STDOUT. If you start them with the
|
231
|
+
`VERBOSE` env variable set, they will print basic debugging
|
232
|
+
information. You can also set the `VVERBOSE` (very verbose) env
|
233
|
+
variable.
|
234
|
+
|
235
|
+
$ VVERBOSE=1 QUEUE=file_serve rake environment resque:work
|
236
|
+
|
237
|
+
|
238
|
+
### Priorities and Queue Lists
|
239
|
+
|
240
|
+
Resque doesn't support numeric priorities but instead uses the order
|
241
|
+
of queues you give it. We call this list of queues the "queue list."
|
242
|
+
|
243
|
+
Let's say we add a `warm_cache` queue in addition to our `file_serve`
|
244
|
+
queue. We'd now start a worker like so:
|
245
|
+
|
246
|
+
$ QUEUES=file_serve,warm_cache rake resque:work
|
247
|
+
|
248
|
+
When the worker looks for new jobs, it will first check
|
249
|
+
`file_serve`. If it finds a job, it'll process it then check
|
250
|
+
`file_serve` again. It will keep checking `file_serve` until no more
|
251
|
+
jobs are available. At that point, it will check `warm_cache`. If it
|
252
|
+
finds a job it'll process it then check `file_serve` (repeating the
|
253
|
+
whole process).
|
254
|
+
|
255
|
+
In this way you can prioritize certain queues. At GitHub we start our
|
256
|
+
workers with something like this:
|
257
|
+
|
258
|
+
$ QUEUES=critical,archive,high,low rake resque:work
|
259
|
+
|
260
|
+
Notice the `archive` queue - it is specialized and in our future
|
261
|
+
architecture will only be run from a single machine.
|
262
|
+
|
263
|
+
At that point we'll start workers on our generalized background
|
264
|
+
machines with this command:
|
265
|
+
|
266
|
+
$ QUEUES=critical,high,low rake resque:work
|
267
|
+
|
268
|
+
And workers on our specialized archive machine with this command:
|
269
|
+
|
270
|
+
$ QUEUE=archive rake resque:work
|
271
|
+
|
272
|
+
|
273
|
+
### Running All Queues
|
274
|
+
|
275
|
+
If you want your workers to work off of every queue, including new
|
276
|
+
queues created on the fly, you can use a splat:
|
277
|
+
|
278
|
+
$ QUEUE=* rake resque:work
|
279
|
+
|
280
|
+
Queues will be processed in alphabetical order.
|
281
|
+
|
282
|
+
|
283
|
+
### Forking
|
284
|
+
|
285
|
+
On certain platforms, when a Resque worker reserves a job it
|
286
|
+
immediately forks a child process. The child processes the job then
|
287
|
+
exits. When the child has exited successfully, the worker reserves
|
288
|
+
another job and repeats the process.
|
289
|
+
|
290
|
+
Why?
|
291
|
+
|
292
|
+
Because Resque assumes chaos.
|
293
|
+
|
294
|
+
Resque assumes your background workers will lock up, run too long, or
|
295
|
+
have unwanted memory growth.
|
296
|
+
|
297
|
+
If Resque workers processed jobs themselves, it'd be hard to whip them
|
298
|
+
into shape. Let's say one is using too much memory: you send it a
|
299
|
+
signal that says "shutdown after you finish processing the current
|
300
|
+
job," and it does so. It then starts up again - loading your entire
|
301
|
+
application environment. This adds useless CPU cycles and causes a
|
302
|
+
delay in queue processing.
|
303
|
+
|
304
|
+
Plus, what if it's using too much memory and has stopped responding to
|
305
|
+
signals?
|
306
|
+
|
307
|
+
Thanks to Resque's parent / child architecture, jobs that use too much memory
|
308
|
+
release that memory upon completion. No unwanted growth.
|
309
|
+
|
310
|
+
And what if a job is running too long? You'd need to `kill -9` it then
|
311
|
+
start the worker again. With Resque's parent / child architecture you
|
312
|
+
can tell the parent to forcefully kill the child then immediately
|
313
|
+
start processing more jobs. No startup delay or wasted cycles.
|
314
|
+
|
315
|
+
The parent / child architecture helps us keep tabs on what workers are
|
316
|
+
doing, too. By eliminating the need to `kill -9` workers we can have
|
317
|
+
parents remove themselves from the global listing of workers. If we
|
318
|
+
just ruthlessly killed workers, we'd need a separate watchdog process
|
319
|
+
to add and remove them to the global listing - which becomes
|
320
|
+
complicated.
|
321
|
+
|
322
|
+
Workers instead handle their own state.
|
323
|
+
|
324
|
+
|
325
|
+
### Parents and Children
|
326
|
+
|
327
|
+
Here's a parent / child pair doing some work:
|
328
|
+
|
329
|
+
$ ps -e -o pid,command | grep [r]esque
|
330
|
+
92099 resque: Forked 92102 at 1253142769
|
331
|
+
92102 resque: Processing file_serve since 1253142769
|
332
|
+
|
333
|
+
You can clearly see that process 92099 forked 92102, which has been
|
334
|
+
working since 1253142769.
|
335
|
+
|
336
|
+
(By advertising the time they began processing you can easily use monit
|
337
|
+
or god to kill stale workers.)
|
338
|
+
|
339
|
+
When a parent process is idle, it lets you know what queues it is
|
340
|
+
waiting for work on:
|
341
|
+
|
342
|
+
$ ps -e -o pid,command | grep [r]esque
|
343
|
+
92099 resque: Waiting for file_serve,warm_cache
|
344
|
+
|
345
|
+
|
346
|
+
### Signals
|
347
|
+
|
348
|
+
Resque workers respond to a few different signals:
|
349
|
+
|
350
|
+
* `QUIT` - Wait for child to finish processing then exit
|
351
|
+
* `TERM` / `INT` - Immediately kill child then exit
|
352
|
+
* `USR1` - Immediately kill child but don't exit
|
353
|
+
|
354
|
+
If you want to gracefully shutdown a Resque worker, use `QUIT`.
|
355
|
+
|
356
|
+
If you want to kill a stale or stuck child, use `USR1`. Processing
|
357
|
+
will continue as normal.
|
358
|
+
|
359
|
+
If you want to kill a stale or stuck child and shutdown, use `TERM`
|
360
|
+
|
361
|
+
|
362
|
+
The Front End
|
363
|
+
-------------
|
364
|
+
|
365
|
+
Resque comes with a Sinatra-based front end for seeing what's up with
|
366
|
+
your queue.
|
367
|
+
|
368
|
+
![The Front End](http://img.skitch.com/20091102-rpekt191w28xfhwyussru44nsw.png)
|
369
|
+
|
370
|
+
## Standalone
|
371
|
+
|
372
|
+
If you've installed Resque as a gem running the front end standalone is easy:
|
373
|
+
|
374
|
+
$ resque-web
|
375
|
+
|
376
|
+
It's a thin layer around `rackup` so it's configurable as well:
|
377
|
+
|
378
|
+
$ resque-web -p 8282
|
379
|
+
|
380
|
+
If you have a Resque config file you want evaluated just pass it to
|
381
|
+
the script as the final argument:
|
382
|
+
|
383
|
+
$ resque-web -p 8282 rails_root/config/initializers/resque.rb
|
384
|
+
|
385
|
+
### Passenger
|
386
|
+
|
387
|
+
Using Passenger? Resque ships with a `config.ru` you can use. See
|
388
|
+
Phusion's guide:
|
389
|
+
|
390
|
+
<http://www.modrails.com/documentation/Users%20guide.html#_deploying_a_rack_based_ruby_application>
|
391
|
+
|
392
|
+
### Rack::URLMap
|
393
|
+
|
394
|
+
If you want to load Resque on a subpath, possibly alongside other
|
395
|
+
apps, it's easy to do with Rack's `URLMap`:
|
396
|
+
|
397
|
+
require 'resque/server'
|
398
|
+
|
399
|
+
run Rack::URLMap.new \
|
400
|
+
"/" => Your::App.new,
|
401
|
+
"/resque" => Resque::Server.new
|
402
|
+
|
403
|
+
Check `examples/demo/config.ru` for a functional example (including
|
404
|
+
HTTP basic auth).
|
405
|
+
|
406
|
+
|
407
|
+
Resque vs DelayedJob
|
408
|
+
--------------------
|
409
|
+
|
410
|
+
How does Resque compare to DelayedJob, and why would you choose one
|
411
|
+
over the other?
|
412
|
+
|
413
|
+
* Resque supports multiple queues
|
414
|
+
* DelayedJob supports finer grained priorities
|
415
|
+
* Resque workers are resilient to memory leaks / bloat
|
416
|
+
* DelayedJob workers are extremely simple and easy to modify
|
417
|
+
* Resque requires Redis
|
418
|
+
* DelayedJob requires ActiveRecord
|
419
|
+
* Resque can only place JSONable Ruby objects on a queue as arguments
|
420
|
+
* DelayedJob can place _any_ Ruby object on its queue as arguments
|
421
|
+
* Resque includes a Sinatra app for monitoring what's going on
|
422
|
+
* DelayedJob can be queryed from within your Rails app if you want to
|
423
|
+
add an interface
|
424
|
+
|
425
|
+
If you're doing Rails development, you already have a database and
|
426
|
+
ActiveRecord. DelayedJob is super easy to setup and works great.
|
427
|
+
GitHub used it for many months to process almost 200 million jobs.
|
428
|
+
|
429
|
+
Choose Resque if:
|
430
|
+
|
431
|
+
* You need multiple queues
|
432
|
+
* You don't care / dislike numeric priorities
|
433
|
+
* You don't need to persist every Ruby object ever
|
434
|
+
* You have potentially huge queues
|
435
|
+
* You want to see what's going on
|
436
|
+
* You expect a lot of failure / chaos
|
437
|
+
* You can setup Redis
|
438
|
+
* You're not running short on RAM
|
439
|
+
|
440
|
+
Choose DelayedJob if:
|
441
|
+
|
442
|
+
* You like numeric priorities
|
443
|
+
* You're not doing a gigantic amount of jobs each day
|
444
|
+
* Your queue stays small and nimble
|
445
|
+
* There is not a lot failure / chaos
|
446
|
+
* You want to easily throw anything on the queue
|
447
|
+
* You don't want to setup Redis
|
448
|
+
|
449
|
+
In no way is Resque a "better" DelayedJob, so make sure you pick the
|
450
|
+
tool that's best for your app.
|
451
|
+
|
452
|
+
|
453
|
+
Installing Redis
|
454
|
+
----------------
|
455
|
+
|
456
|
+
Resque uses Redis' lists for its queues. It also stores worker state
|
457
|
+
data in Redis.
|
458
|
+
|
459
|
+
#### Homebrew
|
460
|
+
|
461
|
+
If you're on OS X, Homebrew is the simplest way to install Redis:
|
462
|
+
|
463
|
+
$ brew install redis
|
464
|
+
$ redis-server /usr/local/etc/redis.conf
|
465
|
+
|
466
|
+
You now have a Redis daemon running on 6379.
|
467
|
+
|
468
|
+
#### Via Resque
|
469
|
+
|
470
|
+
Resque includes Rake tasks (thanks to Ezra's redis-rb) that will
|
471
|
+
install and run Redis for you:
|
472
|
+
|
473
|
+
$ git clone git://github.com/defunkt/resque.git
|
474
|
+
$ cd resque
|
475
|
+
$ rake redis:install dtach:install
|
476
|
+
$ rake redis:start
|
477
|
+
|
478
|
+
You now have Redis running on 6379. Wait a second then hit ctrl-\ to
|
479
|
+
detach and keep it running in the background.
|
480
|
+
|
481
|
+
The demo is probably the best way to figure out how to put the parts
|
482
|
+
together. But, it's not that hard.
|
483
|
+
|
484
|
+
|
485
|
+
Resque Dependencies
|
486
|
+
-------------------
|
487
|
+
|
488
|
+
gem install redis redis-namespace yajl-ruby --source=http://gemcutter.org
|
489
|
+
|
490
|
+
If you cannot install `yajl-ruby` (JRuby?), you can install the `json`
|
491
|
+
gem and Resque will use it instead.
|
492
|
+
|
493
|
+
|
494
|
+
Installing Resque
|
495
|
+
-----------------
|
496
|
+
|
497
|
+
### In a Rack app, as a gem
|
498
|
+
|
499
|
+
First install the gem.
|
500
|
+
|
501
|
+
$ gem install resque --source=http://gemcutter.org
|
502
|
+
|
503
|
+
Next include it in your application.
|
504
|
+
|
505
|
+
require 'resque'
|
506
|
+
|
507
|
+
Now start your application:
|
508
|
+
|
509
|
+
rackup config.ru
|
510
|
+
|
511
|
+
That's it! You can now create Resque jobs from within your app.
|
512
|
+
|
513
|
+
To start a worker, create a Rakefile in your app's root (or add this
|
514
|
+
to an existing Rakefile):
|
515
|
+
|
516
|
+
require 'your/app'
|
517
|
+
require 'resque/tasks'
|
518
|
+
|
519
|
+
Now:
|
520
|
+
|
521
|
+
$ QUEUE=* rake resque:work
|
522
|
+
|
523
|
+
Alternately you can define a `resque:setup` hook in your Rakefile if you
|
524
|
+
don't want to load your app every time rake runs.
|
525
|
+
|
526
|
+
|
527
|
+
### In a Rails app, as a gem
|
528
|
+
|
529
|
+
First install the gem.
|
530
|
+
|
531
|
+
$ gem install resque --source=http://gemcutter.org
|
532
|
+
|
533
|
+
Next include it in your application.
|
534
|
+
|
535
|
+
$ cat config/initializers/load_resque.rb
|
536
|
+
require 'resque'
|
537
|
+
|
538
|
+
Now start your application:
|
539
|
+
|
540
|
+
$ ./script/server
|
541
|
+
|
542
|
+
That's it! You can now create Resque jobs from within your app.
|
543
|
+
|
544
|
+
To start a worker, add this to your Rakefile in RAILS_ROOT:
|
545
|
+
|
546
|
+
require 'resque/tasks'
|
547
|
+
|
548
|
+
Now:
|
549
|
+
|
550
|
+
$ QUEUE=* rake environment resque:work
|
551
|
+
|
552
|
+
Don't forget you can define a `resque:setup` hook in
|
553
|
+
`lib/tasks/whatever.rake` that loads the `environment` task every time.
|
554
|
+
|
555
|
+
|
556
|
+
### In a Rails app, as a plugin
|
557
|
+
|
558
|
+
$ ./script/plugin install git://github.com/defunkt/resque
|
559
|
+
|
560
|
+
That's it! Resque will automatically be available when your Rails app
|
561
|
+
loads.
|
562
|
+
|
563
|
+
To start a worker:
|
564
|
+
|
565
|
+
$ QUEUE=* rake environment resque:work
|
566
|
+
|
567
|
+
Don't forget you can define a `resque:setup` hook in
|
568
|
+
`lib/tasks/whatever.rake` that loads the `environment` task every time.
|
569
|
+
|
570
|
+
|
571
|
+
Configuration
|
572
|
+
-------------
|
573
|
+
|
574
|
+
You may want to change the Redis host and port Resque connects to, or
|
575
|
+
set various other options at startup.
|
576
|
+
|
577
|
+
Resque has a `redis` setter which can be given a string or a Redis
|
578
|
+
object. This means if you're already using Redis in your app, Resque
|
579
|
+
can re-use the existing connection.
|
580
|
+
|
581
|
+
String: `Resque.redis = 'localhost:6379'
|
582
|
+
|
583
|
+
Redis: `Redus.redis = $redis`
|
584
|
+
|
585
|
+
For our rails app we have a `config/initializers/resque.rb` file where
|
586
|
+
we load `config/resque.yml` by hand and set the Redis information
|
587
|
+
appropriately.
|
588
|
+
|
589
|
+
Here's our `config/resque.yml`:
|
590
|
+
|
591
|
+
development: localhost:6379
|
592
|
+
test: localhost:6379
|
593
|
+
staging: redis1.se.github.com:6379
|
594
|
+
fi: localhost:6379
|
595
|
+
production: redis1.ae.github.com:6379
|
596
|
+
|
597
|
+
And our initializer:
|
598
|
+
|
599
|
+
rails_root = ENV['RAILS_ROOT'] || File.dirname(__FILE__) + '/../..'
|
600
|
+
rails_env = ENV['RAILS_ENV'] || 'development'
|
601
|
+
|
602
|
+
resque_config = YAML.load_file(rails_root + '/config/resque.yml')
|
603
|
+
Resque.redis = resque_config[rails_env]
|
604
|
+
|
605
|
+
Easy peasy! Why not just use `RAILS_ROOT` and `RAILS_ENV`? Because
|
606
|
+
this way we can tell our Sinatra app about the config file:
|
607
|
+
|
608
|
+
$ RAILS_ENV=production resque-web rails_root/config/initializers/resque.rb
|
609
|
+
|
610
|
+
Now everyone is on the same page.
|
611
|
+
|
612
|
+
|
613
|
+
Demo
|
614
|
+
----
|
615
|
+
|
616
|
+
Resque ships with a demo Sinatra app for creating jobs that are later
|
617
|
+
processed in the background.
|
618
|
+
|
619
|
+
Try it out by looking at the README, found at `examples/demo/README.markdown`.
|
620
|
+
|
621
|
+
|
622
|
+
Meta
|
623
|
+
----
|
624
|
+
|
625
|
+
* Code: `git clone git://github.com/defunkt/resque.git`
|
626
|
+
* Home: <http://github.com/defunkt/resque>
|
627
|
+
* Docs: <http://defunkt.github.com/resque/>
|
628
|
+
* Bugs: <http://github.com/defunkt/resque/issues>
|
629
|
+
* List: <resque@librelist.com>
|
630
|
+
* Gems: <http://gemcutter.org/gems/resque>
|
631
|
+
|
632
|
+
|
633
|
+
Author
|
634
|
+
------
|
635
|
+
|
636
|
+
Chris Wanstrath :: chris@ozmm.org :: @defunkt
|
637
|
+
|
638
|
+
[0]: http://github.com/blog/542-introducing-resque
|