Thanks for accurate title - this is not a full queueing system, but a unified API for hooking in bigger, badder queueing engines like Resque.
The point is to standardize the interface so other plugins/gems can simple make calls to Rails.queue rather than try to accomodate every queueing engine themselves.
Skimming through the code, this lets you register a Queue class to serialize your jobs. So, if you use something like Delayed Job, you register the (corresponding) DJ::Queue class that stores the jobs in whatever backend you desire and then process it later via your daemon of choice.
So far so peachy keen. This is alright, I can get behind this - it will make moving between queueing solutions more palatable which is not a feature I can complain about.
My question then is: how will this work by default? Will the default Queue have some sort of callback that executes after it returns the response? For stuff like sending emails, for small apps, this is actually palatable - I'm concerned about user latency than sheer requests/second.
J2EE was an entire specification for application frameworks. This is just defining the bridging interface between Rails and any (existing or not) queueing framework. It's already been achieved nicely with Rails.cache.
In any event, the web shows it is actually possible to separate interfaces from implementations. J2EE had other issues.
The point is to standardize the interface so other plugins/gems can simple make calls to Rails.queue rather than try to accomodate every queueing engine themselves.