4 ms·

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 s

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.

phillmv 15y ago
Someone please correct me if I am wrong. 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.
- tlrobinson 15y ago
  It sounds like the default queue implementation is an in memory queue that runs in the same process on another thread.
- tomstuart 15y ago
  The default implementation is a stdlib Queue (http://www.ruby-doc.org/stdlib/libdoc/thread/rdoc/Queue.html http://www.ruby-doc.org/stdlib/libdoc/thread/rdoc/Queue.html) which will be consumed by a Rails::Queueing::ThreadedConsumer (https://github.com/rails/rails/blob/602000b/railties/lib/rails/queueing.rb#L34-63 https://github.com/rails/rails/blob/602000b/railties/lib/rai...). You just drop job objects into the queue, and the consumer thread will call #run on them.
deleted 15y ago
[deleted]
- mmahemoff 15y ago
  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.

phillmv 15y ago

Someone please correct me if I am wrong. 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.

tlrobinson 15y ago
It sounds like the default queue implementation is an in memory queue that runs in the same process on another thread.
tomstuart 15y ago
The default implementation is a stdlib Queue (http://www.ruby-doc.org/stdlib/libdoc/thread/rdoc/Queue.html http://www.ruby-doc.org/stdlib/libdoc/thread/rdoc/Queue.html) which will be consumed by a Rails::Queueing::ThreadedConsumer (https://github.com/rails/rails/blob/602000b/railties/lib/rails/queueing.rb#L34-63 https://github.com/rails/rails/blob/602000b/railties/lib/rai...). You just drop job objects into the queue, and the consumer thread will call #run on them.

deleted 15y ago

[deleted]

mmahemoff 15y ago
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.