I was recently designing an application that needed to execute some long running requests against an external host. If you’ve ever tried doing something like this in Rails, you’ll find your mongrels will block up waiting for the request to complete, bringing the experience for all other users to a halt.

I wanted to dispatch my long running request, return to the user, and then poll for results using AJAX. There are many ways to do background tasks in Rails, most of which require running an out of process background server with which you will communicate over some sort of queue or memcached. There’s BackgroundRb, Bj, workling, and so on, but this seemed overkill for my problem.

After reading a post on using Ruby Threads, I decided to be brave and try this approach. I implemented a simple action which would spawn a thread and proceed to return the result whether it was ready or not. This action is polled via AJAX and on the next poll the result will be correct. The pseudocode looks something like

def long_running_action
  #spawn a thread
  precache_the_results

  # This action throws DataNotAvailableException
  # if file is missing/unreadable
  results = read_cached_results

rescue DataNotAvailableException
  # This tells me that when I load the page
  # I should invoke an ajax a couple seconds
  # later to check for results again
  flash[:update_right_away] = true
ensure
  respond_to do |wants|
    # render an RJS update with the results
  end
end

def precache_the_results
  Thread.new {
    expensive_action_outputs_to("file.txt")
  }
end

Because I didn’t join the Thread to the request thread, it lives on after the request completes, which is just what I needed. Since the code inside my Thread is a call to an external provider and doesn’t write to the database, I am not concerned with ActiveRecord threading issues.

The only problem with this approach is that in development mode, Rails likes to reload your classes on every request. But if your thread runs past the request lifetime, the class that’s running it may be unloaded while it’s running, wreaking all sorts of havoc. But Ruby allows us the power to be truly evil:. What if I just prevent Threads from doing what they want to in development mode? Turns out I can!

if ENV['RAILS_ENV'] == 'development'
  class Thread
    def initialize(&block)
      block.call
    end
  end
end

This code is defined in the class where I’m doing the magic. Do NOT just slap this into your environment.rb as you’ll horribly break the Rails startup logic. There’s probably a slightly smarter and safer way to do this by using a Factory pattern to create the threads and explicitly specifying the implementation you want. But this is my party and I’ll monkeypatch if I want to.

So..comments, suggestions, complaints? Is this going to die horribly in production? I guess we’ll have to see!

This code is written using the shoulda plugin which gives a slightly more verbose breakdown of the setup and the test, but it can be done with test/unit just as well.

context "orphan user migration" do
  setup do
    require "#{RAILS_ROOT}/db/migrate/163_create_orphan_owner"
    CreateOrphanOwner.up
  end
  should "create the orphan user" do
    assert orphan = User.orphan_owner
    assert orphan.role?(User::ORPHAN_OWNER)
  end
end

Of course, only Enterprise Java scales, and we know this because the word Enterprise is right there in the name. Of course, the only platform you should consider is .NET because it has built in caching and hundreds of thousands of college graduates know it. Of course, you need to use PHP because Facebook is written in PHP and Facebook scales. The fallacy of these arguments should be painfully obvious, yet people are shouting these things as if they were gospel truth.

I’d like to offer here, the scalability manifesto. Please repeat these items aloud to yourself every time you want to say something about language X or framework Y not scaling.

The Scalability Manifesto

1. Scalability means the ability to handle increasing load by increasing resources.
2. Scalability does not mean being ‘fast’.
3. Choice of language does not guarantee scalability.
4. Hardware costs decrease exponentially, developer salaries do not.
5. Only you can make your system scale.

Trading performance for development time is generally not a good idea. It’s likely that by the time your application reaches serious traffic levels (if ever), hardware will cost half of what it did when you started. Now does spending twice as much dev time with a lower level language seem justified? Now this is not always the case, but my bet is if you do the math and realize your team of 4 Ruby hackers is doing what a team of 10 Java programmers used to do, you might conclude that linear performance gains due to language choice are not as relevant as hiring smart people who can get work done quickly, and design scalable systems.

There’s no such thing as a free lunch, and that includes scalability.


$LOAD_PATH.reject! { |e| e.include? 'TextMate' }


Full source at http://pastie.org/191922

class Foo < ActiveRecord::Base
  acts_as_versioned :if_changed => [:description_t]
  def versioned_attributes; [:description_t, :planspace_updated_by_id]; end
end

By reading capistrano source I was able to ferret out the places where I had to make minor adjustments, leading to an implementation in roughly 10 lines of code. All I really had to change was how capistrano sorts releases (using the modification date rather than the name of the directory), and how it determine which revision to write to the REVISION file (by making it grep for the proper field in the svn output). The release name itself and repository location was set using the standard capistrano variable based on the TAG passed in from command line.

The pastie is here capistrano 2 svn tag support.

  def caching_method
    @result || begin
      # expensive operation
      foo = expensive_operation_1
      @result = expensive_operation_2 * foo
    end
  end

What would be a fun next step here is to build a social system on top of this once more people are using it and show most commonly bookmarked pages, or ‘people who bookmarked this gem also bookmarked…’.