Permalink
Browse files

Added config.threadsafe! to toggle allow concurrency settings and dis…

…able the dependency loader
  • Loading branch information...
1 parent ddd5525 commit 177a35e711e3b21eac0eb19f03aeae7626e490f5 @josh josh committed Aug 2, 2008
Showing with 17 additions and 0 deletions.
  1. +2 −0 railties/CHANGELOG
  2. +3 −0 railties/environments/production.rb
  3. +12 −0 railties/lib/initializer.rb
View
2 railties/CHANGELOG
@@ -1,5 +1,7 @@
*Edge*
+* Added config.threadsafe! to toggle allow concurrency settings and disable the dependency loader [Josh Peek]
+
* Turn cache_classes on by default [Josh Peek]
* Added configurable eager load paths. Defaults to app/models, app/controllers, and app/helpers [Josh Peek]
View
3 railties/environments/production.rb
@@ -4,6 +4,9 @@
# Code is not reloaded between requests
config.cache_classes = true
+# Enable threaded mode
+# config.threadsafe!
+
# Use a different logger for distributed setups
# config.logger = SyslogLogger.new
View
12 railties/lib/initializer.rb
@@ -768,6 +768,18 @@ def set_root_path!
::RAILS_ROOT.replace @root_path
end
+ # Enable threaded mode. Allows concurrent requests to controller actions and
+ # multiple database connections. Also disables automatic dependency loading
+ # after boot
+ def threadsafe!
+ self.cache_classes = true
+ self.dependency_loading = false
+ self.active_record.allow_concurrency = true
+ self.action_controller.allow_concurrency = true
+ self.to_prepare { Rails.cache.threadsafe! }
+ self
+ end
+
# Loads and returns the contents of the #database_configuration_file. The
# contents of the file are processed via ERB before being sent through
# YAML::load.

11 comments on commit 177a35e

@adambyrtek

This is quite misleading because as far as I know this is not enough to make Rails actually thread-safe, right?

@NZKoz
Ruby on Rails member

@alpha: The work to enable this happened in dozens of earlier changesets, there’s nothing magic here.

Testing indicates that actionpack and activesupport are threadsafe now. We have to merge the connection pooling branch before we can tick the box for active record.

So no, it’s not misleading, you just missed all the fun stuff in earlier commits :)

@adambyrtek

Thanks for you swift reply. I’ve just started to follow Rails development closer, so I’m not fully informed.

Does this mean that all the issues pointed by Zed in the post below have been resolved?
http://www.mail-archive.com/mongrel-users@rubyforge.org/msg00243.html

@dmitryelastic

great news

@NZKoz
Ruby on Rails member

I’d take zed’s comments with a few grains of salt, some good stuff there and the traditional hyperbole.

The DB connection issue is real and remains outstanding. That’s why we need the connection pool branch from nick sieger before we’re ‘done’ here.

Talk of requests crossing threads or objects moving magically between threads is vague hand waving that likely never happened. We’ve heard this before with respect to active record connections, but no one has ever provided a reproducible test case, or a plausible theory that could explain it.

We’re bound to have missed something, threading bugs are notoriously difficult to track down. The more testers the merrier ;)

@NZKoz
Ruby on Rails member

I’d take zed’s comments with a few grains of salt, some good stuff there and the traditional hyperbole.

The DB connection issue is real and remains outstanding. That’s why we need the connection pool branch from nick sieger before we’re ‘done’ here.

Talk of requests crossing threads or objects moving magically between threads is vague hand waving that likely never happened. We’ve heard this before with respect to active record connections, but no one has ever provided a reproducible test case, or a plausible theory that could explain it.

We’re bound to have missed something, threading bugs are notoriously difficult to track down. The more testers the merrier ;)

@NZKoz
Ruby on Rails member

I’d take zed’s comments with a few grains of salt, some good stuff there and the traditional hyperbole.

The DB connection issue is real and remains outstanding. That’s why we need the connection pool branch from nick sieger before we’re ‘done’ here.

Talk of requests crossing threads or objects moving magically between threads is vague hand waving that likely never happened. We’ve heard this before with respect to active record connections, but no one has ever provided a reproducible test case, or a plausible theory that could explain it.

We’re bound to have missed something, threading bugs are notoriously difficult to track down. The more testers the merrier ;)

@adambyrtek

Time to disable the giant Mongrel lock around Rails and do some testing :)

@NZKoz
Ruby on Rails member

We haven’t finished the work, AR will still leak connections like crazy, but initial testing is positive. If you have some other non-AR apps you can test, we’d love to hear about breakage (in lighthouse + the core list ;)) I’ve been using this app as a test base, if you can reproduce breakages with patches to that, then send them my way.

http://github.com/NZKoz/sillytestapp/tree/master

@rdp

I think most of Zed’s problems will have gone away. However, in my own [none rails] tests about a year ago, the problem of methods ‘mysteriously’ being assigned to the wrong thread occurred, and also that of sockets sometimes reading input from another [different] socket also occurred. That being said, the Mongrel guys haven’t experienced that much [it only occurs with very heavy load], and using eventMachine you can avoid it further. But it is still in there…lurking…

If you were to use eventmachine and a single-threaded style architecture [ex: ruby 1.9 + fibers so that it mimics multi-threaded] then I believe you have even less of the same problems. Good luck.
-=R

@rdp

I think most of Zed’s problems will have gone away. However, in my own [none rails] tests about a year ago, the problem of methods ‘mysteriously’ being assigned to the wrong thread occurred, and also that of sockets sometimes reading input from another [different] socket also occurred. That being said, the Mongrel guys haven’t experienced that much [it only occurs with very heavy load], and using eventMachine you can avoid it further. But it is still in there…lurking…

If you were to use eventmachine and a single-threaded style architecture [ex: ruby 1.9 + fibers so that it mimics multi-threaded] then I believe you have even less of the same problems. Good luck.
-=R

Please sign in to comment.