forked from ggoodale/run_later
-
Notifications
You must be signed in to change notification settings - Fork 6
A port of Merb's run_later functionality to thread-safe Rails (>= 3).
License
Zelnox/run_later
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
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
About
A port of Merb's run_later functionality to thread-safe Rails (>= 3).
Resources
License
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published
Languages
- Ruby 100.0%