I've set config.threadsafe! in config/environment.rb  min and max runtimes are at 1.  I'm not sure what more it's looking
for.



INFO: Loading application rails at /international-action
Jun 11, 2009 4:01:46 PM com.sun.grizzly.jruby.RubyRuntime
INFO: Environment: local_ipumsi
Jun 11, 2009 4:01:46 PM com.sun.grizzly.config.GrizzlyServiceListener
INFO: Jruby version is: 1.3.0
Jun 11, 2009 4:01:46 PM  
INFO: Read to serve the request
Jun 11, 2009 4:01:47 PM com.sun.grizzly.config.GrizzlyServiceListener
INFO: Detected Rails application
Jun 11, 2009 4:01:47 PM com.sun.grizzly.config.GrizzlyServiceListener
INFO: Rails not in thread-safe mode, starting in single-thread mode
Jun 11, 2009 4:01:47 PM com.sun.grizzly.scripting.pool.DynamicPool
INFO: Pool started without dynamic resizing enabled. Pool will not attempt to determine the upper and lower bounds that
it should be using, and will stay at 1
Jun 11, 2009 4:01:47 PM javax.enterprise.system.core.com.sun.enterprise.v3.server
INFO: GlassFish v3  startup time : Static(482ms) startup services(3262ms) total(3744ms)

Date: 2009-10-30 23:27
Sender: Vivek Pandey

Fixed and will be part of next gem release. Now it correctly
detects threadsafe rails no matter where it is configured.

You can try interim gem build:
http://download.java.net/maven/glassfish/org/glassfish/scripting/
glassfish-gem/0.9.6-SNAPSHOT/glassfish-gem-0.9.6-SNAPSHOT.gem

Date: 2009-09-26 00:14
Sender: Vivek Pandey

Ok, I started working on it. I patch a method
to Rails::Configuration:

module Rails
  class Configuration
    def threadsafe?
      preload_frameworks && cache_classes &&
!dependency_loading &&
action_controller.allow_concurrency
    end
  end
end

As you can see, cache_classes MUST be false for concurrency to
work. The logic is strictly based on what threadsafe! method
does. However, if your app is running in 'development' then Rails
automatically sets cache_classes to false. I am not sure about
any other custome environment what would Rails do.

Any feedback is appreciated.

Date: 2009-08-31 22:04
Sender: Rich Liebling

It actually doesn't matter that you actually invoke
config.threadsafe!, only (apparently) that the string is found
in the appropriate file.  For example, you can comment it out
and glassfish still thinks you are using threadsafe mode.  I
say this based on three observations:
1.  the message when it goes into threadsafe mode is
"config.threadsafe! sighted", suggesting that it is
merely its appearance that matters
2.  noting that glassfish detects this before it runs the
environment.rb
3.  testing it empirically

Also, it will run in threadsafe mode if the environment
is development, but not (seemingly) arbitrary environment names.

However, i have so far been unable to find the code that performs
this check.  I have checked out these projects:
 * https://svn.dev.java.net/svn/glassfish-svn/trunk/v3
 * https://svn.dev.java.net/svn/glassfish-scripting/tags/glassfis
h-gem-0.9.5
 * https://svn.dev.java.net/svn/glassfish-scripting/trunk/rails/g
em

I have grepped for the strings "sighted"
and "threadsafe!" and not found the code.  Any help
on what project is responsible for this code would be much
appreciated.

Date: 2009-08-03 00:57
Sender: Matthew Ueckerman

Vivek, the URL you've referred to reads:
'To enable multithreaded dispatching in production mode of your
application, add the following line in your
config/environments/production.rb...'

I read this as 'an example' of how to enable multithreading in
production mode, not that it is the 'only way' to enable it.

As Justin's illuded to, a great alternative would be to honor
the value in config.action_controller.allow_concurrency and disregard
the manner in which it is established.

Date: 2009-06-12 16:11
Sender: Justin Coyne

Thanks for entertaining this suggestion Vivek. I'll stay
tuned for updates. :)  Thanks for all your hard work.

Date: 2009-06-12 16:07
Sender: Vivek Pandey

What you said makes sense. I think we have some hard-coding in
our code to only enable threadsafe in production environment.
The fix will be easy and will be in next gem release.

I dont have a good workaround for you unless you can run your
code in production environment. The other thing  I can do is
to give you a gem release with this fix soon.

Date: 2009-06-12 15:59
Sender: Justin Coyne

So, you're not actually getting the configuration object
from ActionController::Base?  My application doesn't have a
"production" environment.  We actually have several
configurations (environments in rails) that operate on
production servers.

I think config.threadsafe! ought to be applicable to any
config block for ActionController::Base. 
So far as I know, there are no other config options that
only work when they are in a specific file, so this is a
drastic departure from the established conventions.  There
are no other features of rails that force me into having an
environment named 'production'.

See http://guides.rails.info/configuring.html (3.2
Configuring Action Controller)

Date: 2009-06-11 22:47
Sender: Vivek Pandey

According to Rails docs[1], to enable multi-threading you need
to run your app in production and add config.threadsafe! inside
config/environments/production.rb. I see you added inside
config/environment.rb.

So here is what you need to do:


* Uncomment config.threadsafe! line
in config/environments/production.rb

* Run glassfish gem in production mode

$ glassfish -e production


[1]http://guides.rubyonrails.org/2_2_release_notes.html#thread-sa
fety