…ping with Rails 4.0.
Setting the action_dispatch.rack_cache options to true or a hash should be the way to enable it.
…ain queues in the classes that use them instead.
…mespaces The new option allows any Ruby namespace to be registered and set up for eager load. We are effectively exposing the structure existing in Rails since v3.0 for all developers in order to make their applications thread-safe and CoW friendly.
The flag was mainly used to add a Rack::Lock middleware to the stack, but the only scenario the lock is desired is in development. If you are deploying on a not-threaded server, the Rack::Lock does not provide any benefit since you don't have concurrent accesses. On the other hand, if you are on a threaded server, you don't want the lock, since it defeats the purpose of using a threaded server. If there is someone out there, running on a thread server and does want a lock, it can be added to your environment as easy as: `use Rack::Lock`
Previously, the eager load behavior was mostly coupled to config.cache_classes, however this was suboptimal since in some environments a developer may want to cache classes but not necessarily load them all on boot (for example, test env). This pull request also promotes the use of config.eager_load set to true by default in production. In the majority of the cases, this is the behavior you want since it will copy most of your app into memory on boot (which was also the previous behavior). Finally, this fix a long standing Rails bug where it was impossible to access a model in a rake task when Rails was set as thread safe.
Closes #7110 there's more work to do on rack-cache issue 69
This allows us to do: In your configuration: Rails.queue[:image_queue] = SomeQueue.new Rails.queue[:mail_queue] = SomeQueue.new In your app code: Rails.queue[:mail_queue].push MailJob.new Both jobs pushed to the same default queue Rails.queue.push DefaultJob.new Rails.queue[:default].push DefaultJob.new
Since plugins were removed, we can clean up a few methods in engines. We also use this opportunity to move `load_console`, `load_tasks` and `load_runner` to Rails::Engine. This means that, if someone wants to improve script/rails for engines to support console or runner commands, part of the work is already done.
railites_order method, introduced in 40b19e0, had a bug that was causing loading application instance twice in initializers if railties_order already included application instance. So for example railties_order = [Foo::Engine, :main_app, Bar::Engine] would result in such railties array: [MyApp::Application, Foo::Engine, MyAppApplication, Bar::Engine] In order to fix it, we need to check for existence of application in both railties_order and railties arrays.