The issue is that ActiveSupport’s autoloading is turned off once threadsafe! is executed because autoloading is inherently thread-unsafe. These plugins were not explicitly requiring their classes in init.rb but instead relying on autoloading like so:

config/environment.rb:

Rails::Initializer.run do |config|
  config.threadsafe!
end
ExceptionNotifier.exception_recipients = %w(mikeATtracknowledge.org)

Yes, ExceptionNotifier was one of the broken plugins along with the GeoKit plugin. The fix is simple:

diff --git a/vendor/plugins/exception_notification/init.rb b/vendor/plugins/exception_notification/init.rb
index b39bd95..b1dd2d9 100644
--- a/vendor/plugins/exception_notification/init.rb
+++ b/vendor/plugins/exception_notification/init.rb
@@ -1 +1,4 @@
 require "action_mailer"
+require 'exception_notifier'
+require 'exception_notifiable'
+require 'exception_notifier_helper'

If you maintain a Rails plugin, make sure you verify that all classes are loaded in init.rb or you could very well have problems too.

Given that my interests lie in server-side performance and scalability, I saw two linked trends developing:

Threads suck (on Ruby?)

They work reasonably well in Java but you should avoid them if humanly possible in Ruby. They have two fundamental drawbacks: 1) the programming model makes safe concurrency difficult to code and test; and 2) the various Ruby VMs have enough differences in their threading models that you can’t get good, reliable concurrency even with well-written multi-threaded code. The current best practice is to move to an evented IO model, which allows a single process to handle many requests concurrently and will peg a single core on a modern processor. To peg all the cores, you should scale with multiple Ruby processes, a la the traditional pack of Mongrels with Rails.

Real concurrency requires a new language

Even if Ruby had Java’s excellent VM and threading model, it still is not suited to developing scalable apps on many-core machines because of its more traditional, mutable state nature. Traditionally pure functional languages excel at concurrency because of their nature: they don’t allow mutable state or “side effects” in the code. Guess what: these are the two things you need to synchronize when dealing with threads; programming in a good functional language means you don’t ever need to worry about synchronization.

A note: new languages should not build their own VM anymore. The Java VM is an incredible feat of engineering and recent languages have starting using it as their platform in order to get a good threading model, excellent garbage collection and a vast array of third-party libraries which can be accessed easily. Scala and Clojure, for example, are two functional languages which leverage the JVM. Clojure is my favorite of the two: it’s more pure, doesn’t have a compilation step (the compilation is done at runtime) and the syntax is much nicer.

My takeaway was that I need to learn a functional programming language. FP and compilers were the two weaknesses I had when I graduated Cornell and it looks like being able to switch modes of thought from iterative to functional will be important to top notch engineers in the future. I’m going look at Clojure and see what I can do with it.

The ideas in this post came from talks by several people: Jim Weirich, Ilya Grigorik and W. Idris Yasser. Kudos to them for excellent talks.

Here’s my RubyConf slides (1MB, Keynote), minus the screencasts I created to demo the two worker modules in action.

There are two modules provided:

• TokenWorker ensures that one process from a group of redundant processes will be elected to perform processing for the next N seconds.
• StaticQueueWorker distributes a predefined set of work to a dynamic set of processes every N seconds.

Both depend on the standard Ruby library and memcached. StaticQueueWorker also depends on net-mdns for Bonjour functionality.

You can find the code on github with a more detailed overview and examples of how to use the modules in your own code. If you find the software useful, please consider recommending me at Working On Rails.

The coverage of the existing parts of Rails (ActiveRecord, ActiveSupport, etc) is very thorough, especially in the PDF. Unless you’re obsessed with Rails, you’ll learn all sorts of tips to clean up your code and save you time. In that sense, the package will pay for itself very quickly. Probably the weakest part of the content is the coverage on I18N. This is a big subject outside of the US and neither the video or PDF give anything more than a cursory treatment, pointing the viewer to a 3rd party website rather than providing code samples and examples like the other content.

On the production side, the RailsEnvy guys are well known for their rapport and sense of humor and this video is no different, full of banter between the two. If you like the RailsEnvy podcasts, you can expect the same here. One small quibble was their use of a background image and on-screen images of Jason and Gregg. I would have preferred a solid colored background with just a voice-over on the technical content so as to not distract my attention.

So will this package turn you from a Rails 2.2 n00b to a ninja? Well, I feel like I have a much better understanding of the changes that occurred and already have noted a few places in my own code (I’m looking at you, link_to) I can clean up once I’ve migrated to Rails 2.2. I still can’t throw a shuriken but I’m definitely closer to getting a black belt in Rails.

I tend to be fanatical about minimizing dependencies as it has bit me several times in the past.  In this case, we were using config.gem to load a test dependency, redgreen.  All that gem does is colorize your test output.  There’s no reason to list it as an application dependency but the team wanted all gems to install with rake gems:install. It didn’t sit right with me at the time but I didn’t feel strongly enough to raise the issue.  Well as it turns out when you add redgreen via config.gem, it adds a test/unit at_exit handler that exhibits some odd behavior, including breaking the test suite on our sandbox/ci server.

I’m not blaming redgreen and I’m not blaming config.gem since we really weren’t using either as designed.  Once it was loaded as normal, everything worked as expected. Lesson reinforced: keep your app’s dependencies as simple as possible. There’s no reason why redgreen should be installed on our production servers.

• San Franscisco Ruby Meetup, Oct 16th
• Austin on Rails, Austin TX, Oct 28th
• RubyConf 2008, Orlando FL, Nov 6-8th
• Raleigh.rb, Raleigh NC, Nov 18th

I’ll be giving my new “Patterns in Distributed Computing” talk, discussing some of the hard problems in the distributed computing space and my own attempts over the last year to solve some of them.

InformIT: MySQL Query Optimization

• @objects.each { |obj| obj.save! } 3.417227 sec
• Metric.import(@objects) 1.374610 sec
• Metric.import(@objects, :validate => false) 0.488830 sec
• Metric.connection.execute(stmt) 0.033689 sec

So the DB driver only takes 3/100s of a second to do the actual insert and return.  Generating a multi-insert statement properly takes almost a half-second.  Proper validation adds almost another second of overhead.  Dumb iteration is slowest of all, due to the repeated round trips to the database.

As a side note, 50% of the overhead in generating the multi-insert statement comes from the DB adapter’s quote method.  It’s too bad Rails can’t enforce a convention of “all identifiers must be database-safe” so quoting isn’t so heavyweight.

In other news, this week marks my first anniversery in the professional Ruby world.  I’m pretty happy with what I’ve achieved so far and I hope the next year is just as fun and challenging.

1. “yum update” to get the latest security and OS updates
2. Install REE.
3. Install Passenger.
4. Configure apache to use REE and Passenger.
5. Deploy my latest tracknowledge source running on Edge Rails (i.e. 2.2 alpha).

You might wonder why I’m running Edge Rails.  Well, I wanted to get the multithreading and connection pooling features in ASAP so I can test them.  DataFabric does rely on some of the innards of ActiveRecord’s ConnectionAdapter class so I’ll probably need to make changes to get it working on ActiveRecord 2.2.

<an hour passes>

And it’s done!  Wow, that was pretty easy.  The hardest part by far was simply updating my app to list its gem dependencies and install those gems in the new gem repo for REE.  Kudos to the Phusion guys for making Rails deployment MUCH MUCH simpler!