public
Description: Ruby on Rails
Homepage: http://rubyonrails.org
Clone URL: git://github.com/rails/rails.git
Added config.threadsafe! to toggle allow concurrency settings and disable the 
dependency loader
josh (author)
Fri Aug 01 22:42:32 -0700 2008
commit  177a35e711e3b21eac0eb19f03aeae7626e490f5
tree    4042c7492cc57d79dc6935ffc0677f5f4426740b
parent  ddd552504bd682d64aa63bd06aa3f74818d48493
...
1
2
 
 
3
4
5
...
1
2
3
4
5
6
7
0
@@ -1,5 +1,7 @@
0
 *Edge*
0
 
0
+* Added config.threadsafe! to toggle allow concurrency settings and disable the dependency loader [Josh Peek]
0
+
0
 * Turn cache_classes on by default [Josh Peek]
0
 
0
 * Added configurable eager load paths. Defaults to app/models, app/controllers, and app/helpers [Josh Peek]
...
4
5
6
 
 
 
7
8
9
...
4
5
6
7
8
9
10
11
12
0
@@ -4,6 +4,9 @@
0
 # Code is not reloaded between requests
0
 config.cache_classes = true
0
 
0
+# Enable threaded mode
0
+# config.threadsafe!
0
+
0
 # Use a different logger for distributed setups
0
 # config.logger = SyslogLogger.new
0
 
...
768
769
770
 
 
 
 
 
 
 
 
 
 
 
 
771
772
773
...
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
0
@@ -768,6 +768,18 @@ Run `rake gems:install` to install the missing gems.
0
       ::RAILS_ROOT.replace @root_path
0
     end
0
 
0
+    # Enable threaded mode. Allows concurrent requests to controller actions and
0
+    # multiple database connections. Also disables automatic dependency loading
0
+    # after boot
0
+    def threadsafe!
0
+      self.cache_classes = true
0
+      self.dependency_loading = false
0
+      self.active_record.allow_concurrency = true
0
+      self.action_controller.allow_concurrency = true
0
+      self.to_prepare { Rails.cache.threadsafe! }
0
+      self
0
+    end
0
+
0
     # Loads and returns the contents of the #database_configuration_file. The
0
     # contents of the file are processed via ERB before being sent through
0
     # YAML::load.

Comments

alpha Wed Aug 06 05:42:55 -0700 2008

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

NZKoz Wed Aug 06 07:10:23 -0700 2008

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

alpha Wed Aug 06 07:26:11 -0700 2008

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

dmitry12 Wed Aug 06 07:34:30 -0700 2008

great news

NZKoz Wed Aug 06 09:57:52 -0700 2008

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 Wed Aug 06 09:57:57 -0700 2008

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 Wed Aug 06 09:58:21 -0700 2008

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

alpha Wed Aug 06 10:27:55 -0700 2008

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

NZKoz Wed Aug 06 12:15:57 -0700 2008

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

rogerdpack Wed Aug 20 13:29:31 -0700 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

rogerdpack Wed Aug 20 13:30:31 -0700 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