Skip to content
This repository
Browse code

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

…able the dependency loader
  • Loading branch information...
commit 177a35e711e3b21eac0eb19f03aeae7626e490f5 1 parent ddd5525
Joshua Peek authored August 02, 2008
2  railties/CHANGELOG
... ...
@@ -1,5 +1,7 @@
1 1
 *Edge*
2 2
 
  3
+* Added config.threadsafe! to toggle allow concurrency settings and disable the dependency loader [Josh Peek]
  4
+
3 5
 * Turn cache_classes on by default [Josh Peek]
4 6
 
5 7
 * Added configurable eager load paths. Defaults to app/models, app/controllers, and app/helpers [Josh Peek]
3  railties/environments/production.rb
@@ -4,6 +4,9 @@
4 4
 # Code is not reloaded between requests
5 5
 config.cache_classes = true
6 6
 
  7
+# Enable threaded mode
  8
+# config.threadsafe!
  9
+
7 10
 # Use a different logger for distributed setups
8 11
 # config.logger = SyslogLogger.new
9 12
 
12  railties/lib/initializer.rb
@@ -768,6 +768,18 @@ def set_root_path!
768 768
       ::RAILS_ROOT.replace @root_path
769 769
     end
770 770
 
  771
+    # Enable threaded mode. Allows concurrent requests to controller actions and
  772
+    # multiple database connections. Also disables automatic dependency loading
  773
+    # after boot
  774
+    def threadsafe!
  775
+      self.cache_classes = true
  776
+      self.dependency_loading = false
  777
+      self.active_record.allow_concurrency = true
  778
+      self.action_controller.allow_concurrency = true
  779
+      self.to_prepare { Rails.cache.threadsafe! }
  780
+      self
  781
+    end
  782
+
771 783
     # Loads and returns the contents of the #database_configuration_file. The
772 784
     # contents of the file are processed via ERB before being sent through
773 785
     # YAML::load.

11 notes on commit 177a35e

Adam Byrtek

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

Michael Koziarski
Owner

@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 :)

Adam Byrtek

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

great news

Michael Koziarski
Owner

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 ;)

Michael Koziarski
Owner

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 ;)

Michael Koziarski
Owner

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 ;)

Adam Byrtek

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

Michael Koziarski
Owner

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

Roger Pack
rdp commented on 177a35e August 20, 2008

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

Roger Pack
rdp commented on 177a35e August 20, 2008

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.
Something went wrong with that request. Please try again.