forked from Zelnox/run_later
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
62 lines (45 loc) · 2.97 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
RunLater
========
This fork of run_later only works with Rails 3. The original version working with Rails >=2.2 can be found at http://github.com/mattmatt/run_later. To use with Rails3/Bundler, add
gem 'run_later', :git => 'git://github.com/jkraemer/run_later.git'
to your Gemfile.
Simply a blatant port of Merb's run_later method, taking advantage of Rails 2.2 thread safety. Neat as it is, it also works in Rails 2.3.
Runs longer running tasks outside the current request thread, so that the request will return
the content to the user without blocking. Once the request is done, the worker will run the
specified block in a separate thread.
Should an error occur inside the block handed to run_later, the block will be discarded, and the
worker thread will just continue its work without looking back. If you're executing important code
inside the block, ensure that it does proper error handling.
Be warned though, not to run overly long tasks using run_later, especially when you need reliable queue processing. Use a custom daemon or delayed_job in this case. run_later will usually run happily and merrily, but it's best suited for tasks that just could potentially block the request, like sending mail or firing off requests to external web services.
Testing
=======
For testing you can explicitly disable threading of your blocks. Set RunLater.run_now to true in
your config/environments/test.rb and your blocks will be executed within the test case for your
testing pleasure.
Example
=======
class AccountController < ApplicationController
def signup
@user = User.new(params[:user])
if @user.save
run_later do
AccountMailer.deliver_signup(@user)
end
end
end
end
Known Issues
============
When using Passenger (http://modrails.com) and you're running tasks that take a little longer
you will experience a delay in development mode. This is because after each request, Rails
cleans up its environment and unloads all classes. run_later will defer the cleanup until
the worker thread is done or a timeout has occured (default is 10 seconds). This is true
for at least Passenger 2.0.6, but not in 2.0.3 and 2.1.1 (though with Rails 2.3 I experienced it again), and it will also happen when
using Mongrel, but not in production mode. Whatever combination you're using be prepared not to run very long tasks on your development machine.
This is because Rails unloads all classes after a request when class caching is disabled. run_later defers the unloading until the worker thread supposably has finished its tasks, or kills the thread after a timeout of ten seconds. In production mode you won't experience this issue unless of course, you like disabling class caching in production mode.
License, Props
==============
Thanks to Yehuda Katz for showing off run_later at the Merb BoF session at RailsConf Europe 2008.
Ported to Rails by Mathias Meyer (http://paperplanes.de).
Updated to work with Rails 3 by Jens Krämer (http://www.jkraemer.net/).
Released under the MIT license