This project is archived and is in readonly mode.

#1897 ✓wontfix
Joseph Chen

Rails 2.2 auto source code reloading broken when using config.threadsafe!

Reported by Joseph Chen | February 6th, 2009 @ 05:25 PM | in 2.x

If config.threadsafe! is added to config/environments/development.rb, then auto source code reloading stops working.

I noticed that I would make a change to a view and would always have to restart the server before the change would take effect. After a few hours of debugging, I finally tracked it down to this configuration setting.

To reproduce this problem, I simply created a new Rails 2.2 project, generated a scaffold for something, and then added config.threadsafe! to the development.rb. Changes to views don't take effect until restarting the server.

Comments and changes to this ticket

  • DHH

    DHH February 7th, 2009 @ 01:39 PM

    • Assigned user set to “josh”
  • josh

    josh February 7th, 2009 @ 05:00 PM

    • State changed from “new” to “wontfix”

    You cannot run a threadsafe development environment. Reloading classes is not threadsafe, thats why threadsafe! intentionally disables class reloading.

  • Joseph Chen

    Joseph Chen February 9th, 2009 @ 07:13 PM

    There are 2 separate issues here:

    1) Threadsafe development environment not supported:

    Why is threadsafe development environment not supported? Technically, it can be implemented, right? What is it in Rails that prevents us from supporting threadsafe reloading of classes? I see that you marked the bug as wontfix. Is this because the problem cannot be solved? Or is it because it is not worth solving and would involve too much time?

    There is NO indication anywhere that the above is not supported. There is no documentation saying this is not supported. Nor are any errors or warnings displayed when threadsafe! is configured in development mode. At the VERY LEAST, you should put a warning in the console saying that you have threadsafety disabled and are running in dev mode.

    We spent several hours tracking this bug down and it was very frustrating. A simple message somewhere would have saved us a lot of time. I'm sure that this is probably going to come up more and more often as more people move over to 2.2 threadsafe code, and definitely are going to want to test their code in a threadsafe development mode.

    2) Intentionally disabling class reloading for development mode is AGAINST the whole spirit of Ruby on Rails. Why was this solution implemented? Think about it... every time I make any change in a view, model, controller, etc. I have to restart the server. The whole idea of rapid development and DRY.. well throw that out the window because everytime I make even the most minute change, I have to restart the server.

    I would much rather have threadsafety ALWAYS disabled in development mode and keep class reloading than the other way around.

  • Hongli Lai

    Hongli Lai February 9th, 2009 @ 08:36 PM

    Joseph Chen, it is not implemented because it cannot be implemented. Thread-safety is fundamentally incompatible with class reloading. Asking for a thread-safe environment that also supports class reloading is like asking a person to hold a speech while chewing on food. It cannot be done.

  • Hongli Lai

    Hongli Lai February 9th, 2009 @ 08:37 PM

    But you have a point: if it cannot be supported, Rails should at least output a warning when one tries to do both. It should also be documented.

  • DHH

    DHH February 10th, 2009 @ 10:32 AM

    The core point also being that running something in a thread-safe environment is a performance optimization technique. It doesn't matter for development mode. Just like you don't run with class caching turned on either.

  • Joseph Chen

    Joseph Chen February 10th, 2009 @ 05:13 PM

    Thank you Hongli and DHH for the explanations.

    DHH - I agree with you that in general, running in thread-safe mode is more of a performance optimization, like caching. But there are always exceptions to this - at times, I have enabled caching in development mode to try to track down an issue that we suspected was caused by having caching turned on.

    But never mind about caching, that's a separate issue... we have a few reasons why we had enabled threadsafe mode in development:

    1) We were working with DataFabric's ActiveRecord sharding plugin and after we ran into some difficulty setting it up, we wanted to make sure that the plugin worked with ActiveRecord 2.2. The plugin involves thread local storage and thread pooling when running under ActiveRecord 2.2, and not knowing what the problem was, we were trying to debug the issue. Thinking that maybe this might have something to do with threadsafety, we enabled the flag while debugging.

    2) We were interested in using JRuby and had read about the benefits of having threadsafe turned on for JRuby. I would imagine that most users of Rails under JRuby would want to have the threadsafety turned on by default in development mode.

    3) We were not aware of any drawbacks to having threadsafety turned on in development mode. In general, I think that having the development environment match up to the production environment as closely as possible without significantly impacting productivity is a good practice because then you can catch things that might come up in production earlier. In our case, if there are no drawbacks, then why not enable it? In retrospect, had there been some documentation or warning about not enable this feature in development mode, we would not have done this.

  • CancelProfileIsBroken

    CancelProfileIsBroken February 10th, 2009 @ 05:36 PM

    I added some documentation to be more explicit about this in the docrails project. It'll merge back to core rails, and show up on the Rails Guides site, presently.

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href=""></a>

People watching this ticket