I took a very brief perusal through the JRuby Rack code:
http://wiki.jruby.org/wiki/JRuby_Rack
From reading the code, it doesn’t look like min runtimes is used
anywhere. I do see some code that appears to reference it in
PoolingRackApplicationFactory, but I can’t tell how it is being used. Is
it used for anything or is it just a throwback to Goldspike?
Also, Goldspike used to log where you were at in the pool as requests
came in. This was useful - I see a couple log statements in the code
that look like they may do this, but I’m not seeing them occur in my
usage:
mike@mike-laptop:~/projects/jruby-rack/src/main/java/org$ rgrep log *
jruby/rack/SharedRackApplicationFactory.java:
servletContext.log(“unable to create shared application instance”, ex);
jruby/rack/DefaultRackDispatcher.java:
servletContext.log(“Error: Couldn’t handle error: response committed”,
re);
jruby/rack/DefaultRackDispatcher.java:
servletContext.log(“Exception caught”, re);
jruby/rack/DefaultRackDispatcher.java:
servletContext.log(“Error: Couldn’t handle error”, e);
jruby/rack/DefaultRackApplicationFactory.java:
servletContext.log(
jruby/rack/RackServletContextListener.java: ctx.log(“Error:
application initialization failed”, ex);
jruby/rack/PoolingRackApplicationFactory.java:
servletContext.log(“Info: using runtime pool timeout of " + timeout + "
seconds”);
jruby/rack/PoolingRackApplicationFactory.java:
servletContext.log("Info: add application to the pool. size now =
"
jruby/rack/PoolingRackApplicationFactory.java:
servletContext.log(“Error: unable to initialize application”, ex);
jruby/rack/PoolingRackApplicationFactory.java:
servletContext.log(“Warning: no " + end + " runtimes specified.”);
jruby/rack/PoolingRackApplicationFactory.java:
servletContext.log("Info: received " + end + " runtimes = " + v);
The only log statement I ever see is:
INFO: Info: received max runtimes = 10
What got me looking into this is our database config. We’re currently
using postgres-pr, but likely will be moving away from it to JDBC. In
monitoring postgres connections I only see 1 connection coming in, even
with multiple concurrent requests - this seems odd to me - I’d assume
that each Rails runtime would have its own connection. Can someone set
me straight on this?
Thanks,
Mike
–
Mike H.
Program Manager, Collaborative Software Initiative
[email protected]
Portland, Or 97258
http://www.csinitiative.com
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Forgive all the questions …
I’ve been looking more closely at the Rack code - I’m assuming I’m
missing it, but I don’t see where the number of RackApplications (Rails
instances) grows to meet the max (i.e.,
config.webxml.jruby.max.runtimes) - I just see that at init time the min
number of RackApplications are created and held in a pool - then at
runtime they are handed out. I see a timeout, but I don’t see where it
is used to incrementally grow the size of the pool.
Can someone please set me straight?
Thanks,
Mike
Mike H. wrote:
twice now.
mike@mike-laptop:~/projects/jruby-rack/src/main/java/org$ rgrep log *
application initialization failed", ex);
servletContext.log("Info: received " + end + " runtimes = " + v);
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
I looked at the code more closely.
For some TBD reason, JRuby Rack was not picking up my:
config.webxml.jruby.min.runtimes = 10
I verified that the web.xml had:
jruby.min.runtimes
10
From reading the Rack code, it should pick that up, but I got a warning
error that it doesn’t.
When I went back and added the old Goldspike config it did pick it up
and pre-initialize things:
config.webxml.jruby.pool.minIdle = 10
At some point I think that the Goldspike config options should just be
removed entirely and just have 1 way to configure - its confused me
twice now.
Also, each RackApplication (Rails instance in my case) does indeed grab
a connection to the database (I assumed this, but was confused based on
the behavior I was seeing earlier).
This brings me back to my original question: pre a stable Rails 2.2
(multi-threaded) is there any reason that we would want a JDBC
connection pool? Seems useless unless its multi threaded.
Mike
Mike H.
Program Manager, Collaborative Software Initiative
[email protected]
Portland, Or 97258
http://www.csinitiative.com
Mike H. wrote:
that look like they may do this, but I’m not seeing them occur in my usage:
jruby/rack/DefaultRackApplicationFactory.java: servletContext.log(
jruby/rack/PoolingRackApplicationFactory.java: servletContext.log("Info:
me straight on this?
Thanks,
Mike
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Hi Mike,
On Sat, Oct 25, 2008 at 6:36 PM, Mike H. [email protected]
wrote:
now.
Sorry about the trouble – there was a bug fixed recently that looked
for the value under a different (wrong) key than what is in the
documentation. I had always intended to use min/max.runtimes. I agree
that the goldspike options should be removed for clarity.
Also, each RackApplication (Rails instance in my case) does indeed grab a
connection to the database (I assumed this, but was confused based on the
behavior I was seeing earlier).
This brings me back to my original question: pre a stable Rails 2.2
(multi-threaded) is there any reason that we would want a JDBC connection
pool? Seems useless unless its multi threaded.
I agree, I don’t think there’s a huge difference unless your database
driver has troubles with connections that remain checked out from the
connection pool for a long period of time.
/Nick
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
On Sun, Oct 26, 2008 at 9:47 AM, Mike H. [email protected]
wrote:
Forgive all the questions …
I’ve been looking more closely at the Rack code - I’m assuming I’m missing
it, but I don’t see where the number of RackApplications (Rails instances)
grows to meet the max (i.e., config.webxml.jruby.max.runtimes) - I just see
that at init time the min number of RackApplications are created and held in
a pool - then at runtime they are handed out. I see a timeout, but I don’t
see where it is used to incrementally grow the size of the pool.
Can someone please set me straight?
In PoolingRackApplicationFactory a new runtime is created up to the
maximum if there are no runtimes available and the size of the pool is
smaller than the max. There was another bug here recently with the
synchronization semaphore that caused the maximum number of runtimes
to be ignored.
/Nick
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
On Sat, Oct 25, 2008 at 9:36 PM, Mike H. [email protected]
wrote:
This brings me back to my original question: pre a stable Rails 2.2
(multi-threaded) is there any reason that we would want a JDBC connection
pool? Seems useless unless its multi threaded.
You could have many apps (other than rails one) accessing the same
database
and you probably would want to share the available connections.
–
Fabio K.
Caelum - Ensino e Inovação
http://www.caelum.com.br
Yeah I talked about it with Ryan B. - a contributor to
activerecord-jdbc who also works for Collaborative Software Initiative &
he said the same thing - connection pools can be a blessing and a
curse with stale connections / restarted databases etc. Every system
I’ve seen has battled with this sort of thing. From my observations,
rails isn’t terribly smart about this out of the box - it creates and
holds a connection, but if it gets snipped, its gone and rails needs to
be restarted. A connection pool configured to deal with this can be
helpful (test for stale connection, purge old ones, etc.)
We’re currently using postgres-pr which works, but isn’t maintained.
We’ll likely move to the JDBC Postgres driver - currently there are some
AR issues however with migrations.
Mike
Fabio K. wrote:
database and you probably would want to share the available connections.
–
Fabio K.
http://www.fabiokung.com
Caelum - Ensino e Inovação
http://www.caelum.com.br
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
One fix was in 230, and the other was in 218. For reference the 0.9.2
release was made based on 223.
/Nick
On Mon, Oct 27, 2008 at 10:17 AM, Mike H. [email protected]
wrote:
On Sun, Oct 26, 2008 at 9:47 AM, Mike H. [email protected]
that at init time the min number of RackApplications are created and held
synchronization semaphore that caused the maximum number of runtimes
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Thanks Nick - I’m looking at the r235 SVN code - does that have the fix
in it? Can you point out where to look in the code (line #), I’m not
seeing where the pool grows.
And thanks for all your efforts on Warbler & Rack.
Mike
Nick S. wrote:
Can someone please set me straight?
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Thanks Nick.
Well that explains a bunch, thanks.
We are still on Warbler .9.9.
I’ve been able to beet it into submission so that it creates N runtimes.
But obviously I want to upgrade to the more recent bits.
I tried both .9.10 and .9.11 and am getting the folliwng error on any
warbler command. I didn’t see anything obvious in the History file on
anything I should do to upgrade?
Mike
mike@mike-laptop:~/projects/trisano-full/webapp$ jruby -S warble war
java.lang.String:398:in checkBounds': java.lang.StringIndexOutOfBoundsException: String index out of range: -6 from java.lang.String:443:in ’
from org.jruby.util.Dir:799:in newStringFromUTF8' from org.jruby.util.Dir:622:in glob_helper’
from org.jruby.util.Dir:676:in glob_helper' from org.jruby.util.Dir:676:in glob_helper’
from org.jruby.util.Dir:451:in push_globs' from org.jruby.util.Dir:425:in push_braces’
from org.jruby.util.Dir:304:in push_glob' from org.jruby.RubyDir:165:in aref’
from org.jruby.RubyDir$s_method_0_0$RUBYINVOKER$aref:-1:in
call' from org.jruby.internal.runtime.methods.JavaMethod$JavaMethodNoBlock:62:in call’
from org.jruby.internal.runtime.methods.DynamicMethod:242:in
call' from org.jruby.internal.runtime.methods.DynamicMethod:151:in call’
from org.jruby.runtime.CallSite$InlineCachingCallSite:391:in
call' from org.jruby.ast.CallOneArgNode:57:in interpret’
from org.jruby.ast.CallNoArgBlockNode:58:in interpret' from org.jruby.ast.NewlineNode:101:in interpret’
from org.jruby.internal.runtime.methods.DefaultMethod:163:in
interpretedCall' from org.jruby.internal.runtime.methods.DefaultMethod:140:in call’
from org.jruby.internal.runtime.methods.DefaultMethod:253:in
call' from org.jruby.runtime.CallSite$InlineCachingCallSite:391:in call’
from org.jruby.ast.FCallOneArgNode:36:in interpret' from org.jruby.ast.NewlineNode:101:in interpret’
from org.jruby.ast.WhenNode:97:in interpret' from org.jruby.ast.CaseNode:160:in interpret’
from org.jruby.ast.NewlineNode:101:in interpret' from org.jruby.internal.runtime.methods.DefaultMethod:163:in interpretedCall’
from org.jruby.internal.runtime.methods.DefaultMethod:140:in
call' from org.jruby.internal.runtime.methods.DefaultMethod:253:in call’
from org.jruby.runtime.CallSite$InlineCachingCallSite:391:in
call' from org.jruby.ast.FCallOneArgNode:36:in interpret’
from org.jruby.ast.NewlineNode:101:in interpret' from org.jruby.runtime.InterpretedBlock:202:in evalBlockBody’
from org.jruby.runtime.InterpretedBlock:153:in yield' from org.jruby.runtime.Block:105:in yield’
from org.jruby.RubyArray:1415:in each' from org.jruby.RubyArray$i_method_0_0$RUBYFRAMEDINVOKER$each:-1:in call’
from org.jruby.runtime.CallSite$InlineCachingCallSite:352:in
call' from org.jruby.ast.CallNoArgBlockNode:63:in interpret’
from org.jruby.ast.NewlineNode:101:in interpret' from org.jruby.ast.BlockNode:67:in interpret’
from org.jruby.ast.IfNode:108:in interpret' from org.jruby.ast.NewlineNode:101:in interpret’
from org.jruby.ast.BlockNode:67:in interpret' from org.jruby.internal.runtime.methods.DefaultMethod:163:in interpretedCall’
from org.jruby.internal.runtime.methods.DefaultMethod:140:in
call' from org.jruby.internal.runtime.methods.DefaultMethod:211:in call’
from org.jruby.runtime.CallSite$InlineCachingCallSite:132:in
cacheAndCall' from org.jruby.runtime.CallSite$InlineCachingCallSite:343:in call’
from org.jruby.ast.VCallNode:82:in interpret' from org.jruby.ast.NewlineNode:101:in interpret’
from org.jruby.ast.BlockNode:67:in interpret' from org.jruby.internal.runtime.methods.DefaultMethod:163:in interpretedCall’
from org.jruby.internal.runtime.methods.DefaultMethod:140:in
call' from org.jruby.internal.runtime.methods.DefaultMethod:211:in call’
from org.jruby.runtime.CallSite$InlineCachingCallSite:132:in
cacheAndCall' from org.jruby.runtime.CallSite$InlineCachingCallSite:343:in call’
from org.jruby.ast.VCallNode:82:in interpret' from org.jruby.ast.NewlineNode:101:in interpret’
from org.jruby.internal.runtime.methods.DefaultMethod:163:in
interpretedCall' from org.jruby.internal.runtime.methods.DefaultMethod:140:in call’
from org.jruby.internal.runtime.methods.DefaultMethod:211:in
call' from org.jruby.RubyClass:418:in finvoke’
from org.jruby.javasupport.util.RuntimeHelpers:339:in invoke' from org.jruby.RubyObject:724:in callMethod’
from org.jruby.util.TypeConverter:50:in convertToType' from org.jruby.util.TypeConverter:81:in convertToType’
from org.jruby.RubyObject:760:in convertToArray' from org.jruby.RubyArray:2267:in op_plus’
from org.jruby.RubyArray$i_method_1_0$RUBYINVOKER$op_plus:-1:in
call' from org.jruby.internal.runtime.methods.JavaMethod$JavaMethodOne:499:in call’
from org.jruby.internal.runtime.methods.DynamicMethod:242:in
call' from org.jruby.RubyClass:362:in finvoke’
from org.jruby.RubyObject:2048:in send' from org.jruby.RubyObject$i_method_multi$RUBYINVOKER$send:-1:in call’
from org.jruby.runtime.CallSite$InlineCachingCallSite:454:in
call' from org.jruby.ast.CallSpecialArgBlockPassNode:65:in interpret’
from org.jruby.ast.LocalAsgnNode:115:in interpret' from org.jruby.ast.NewlineNode:101:in interpret’
from org.jruby.ast.BlockNode:67:in interpret' from org.jruby.internal.runtime.methods.DefaultMethod:163:in interpretedCall’
from org.jruby.internal.runtime.methods.DefaultMethod:140:in
call' from org.jruby.internal.runtime.methods.DefaultMethod:253:in call’
from org.jruby.runtime.CallSite$InlineCachingCallSite:156:in
cacheAndCall' from org.jruby.runtime.CallSite$InlineCachingCallSite:394:in call’
from org.jruby.ast.CallOneArgNode:57:in interpret' from org.jruby.ast.InstAsgnNode:88:in interpret’
from org.jruby.ast.IfNode:108:in interpret' from org.jruby.ast.NewlineNode:101:in interpret’
from org.jruby.ast.BlockNode:67:in interpret' from org.jruby.internal.runtime.methods.DefaultMethod:163:in interpretedCall’
from org.jruby.internal.runtime.methods.DefaultMethod:140:in
call' from org.jruby.internal.runtime.methods.DefaultMethod:232:in call’
from org.jruby.runtime.CallSite$InlineCachingCallSite:144:in
cacheAndCall' from org.jruby.runtime.CallSite$InlineCachingCallSite:355:in call’
from org.jruby.RubyClass$SpecificArityNew:539:in call' from org.jruby.runtime.CallSite$InlineCachingCallSite:144:in cacheAndCall’
from org.jruby.runtime.CallSite$InlineCachingCallSite:355:in
call' from org.jruby.ast.CallNoArgBlockNode:63:in interpret’
from org.jruby.ast.NewlineNode:101:in interpret' from org.jruby.ast.RootNode:126:in interpret’
from org.jruby.evaluator.ASTInterpreter:123:in
evalWithBinding' from org.jruby.RubyKernel:862:in eval’
from
org.jruby.RubyKernel$s_method_0_3$RUBYFRAMEDINVOKER$eval:-1:in call' from org.jruby.internal.runtime.methods.DynamicMethod:242:in call’
from org.jruby.internal.runtime.methods.DynamicMethod:151:in
call' from org.jruby.runtime.CallSite$InlineCachingCallSite:156:in cacheAndCall’
from org.jruby.runtime.CallSite$InlineCachingCallSite:394:in
call' from org.jruby.ast.FCallOneArgNode:36:in interpret’
from org.jruby.ast.InstAsgnNode:88:in interpret' from org.jruby.ast.NewlineNode:101:in interpret’
from org.jruby.ast.IfNode:108:in interpret' from org.jruby.ast.NewlineNode:101:in interpret’
from org.jruby.ast.BlockNode:67:in interpret' from org.jruby.internal.runtime.methods.DefaultMethod:163:in interpretedCall’
from org.jruby.internal.runtime.methods.DefaultMethod:140:in
call' from org.jruby.internal.runtime.methods.DefaultMethod:232:in call’
from org.jruby.runtime.CallSite$InlineCachingCallSite:144:in
cacheAndCall' from org.jruby.runtime.CallSite$InlineCachingCallSite:355:in call’
from org.jruby.RubyClass$SpecificArityNew:539:in call' from org.jruby.internal.runtime.methods.DynamicMethod:202:in call’
from org.jruby.runtime.CallSite$InlineCachingCallSite:132:in
cacheAndCall' from org.jruby.runtime.CallSite$InlineCachingCallSite:343:in call’
from org.jruby.ast.CallNoArgNode:61:in interpret' from org.jruby.ast.NewlineNode:101:in interpret’
from org.jruby.ast.BlockNode:67:in interpret' from org.jruby.runtime.InterpretedBlock:202:in evalBlockBody’
from org.jruby.runtime.InterpretedBlock:190:in yield' from org.jruby.runtime.Block:110:in yield’
from org.jruby.ast.YieldNode:95:in interpret' from org.jruby.ast.NewlineNode:101:in interpret’
from org.jruby.ast.RescueNode:222:in executeBody' from org.jruby.ast.RescueNode:144:in interpretWithJavaExceptions’
from org.jruby.ast.RescueNode:107:in interpret' from org.jruby.ast.BeginNode:80:in interpret’
from org.jruby.ast.NewlineNode:101:in interpret' from org.jruby.internal.runtime.methods.DefaultMethod:163:in interpretedCall’
from org.jruby.internal.runtime.methods.DefaultMethod:140:in
call' from org.jruby.internal.runtime.methods.DefaultMethod:232:in call’
from org.jruby.runtime.CallSite$InlineCachingCallSite:144:in
cacheAndCall' from org.jruby.runtime.CallSite$InlineCachingCallSite:355:in call’
from org.jruby.ast.CallNoArgBlockNode:63:in interpret' from org.jruby.ast.NewlineNode:101:in interpret’
from org.jruby.ast.BlockNode:67:in interpret' from org.jruby.ast.RootNode:126:in interpret’
from org.jruby.Ruby:2107:in loadFile' from org.jruby.runtime.load.ExternalScript:58:in load’
from org.jruby.runtime.load.LoadService:221:in load' from org.jruby.RubyKernel:830:in load’
from
org.jruby.RubyKernel$s_method_0_1$RUBYFRAMEDINVOKER$load:-1:in call' from org.jruby.internal.runtime.methods.DynamicMethod:242:in call’
from org.jruby.internal.runtime.methods.DynamicMethod:151:in
call' from org.jruby.runtime.CallSite$InlineCachingCallSite:156:in cacheAndCall’
from org.jruby.runtime.CallSite$InlineCachingCallSite:394:in
call' from home.mike.opt.jruby_minus_1_dot_1_dot_4.bin.warble:19:in file’
from home.mike.opt.jruby_minus_1_dot_1_dot_4.bin.warble:-1:in
__file__' from home.mike.opt.jruby_minus_1_dot_1_dot_4.bin.warble:-1:in load’
from org.jruby.Ruby:544:in runScript' from org.jruby.Ruby:457:in runNormally’
from org.jruby.Ruby:330:in runFromMain' from org.jruby.Main:214:in run’
from org.jruby.Main:100:in run' from org.jruby.Main:84:in main’
Nick S. wrote:
And thanks for all your efforts on Warbler & Rack.
it, but I don’t see where the number of RackApplications (Rails
In PoolingRackApplicationFactory a new runtime is created up to the
http://xircles.codehaus.org/manage_email
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
On Mon, Oct 27, 2008 at 1:16 PM, Mike H. [email protected]
wrote:
I tried both .9.10 and .9.11 and am getting the folliwng error on any
from org.jruby.util.Dir:622:in glob_helper' from org.jruby.util.Dir:676:in glob_helper’
from org.jruby.util.Dir:676:in `glob_helper’
This would seem more indicative of something wrong with your installed
JRuby rather than warbler itself. Does running with --trace give you
any more useful information?
/Nick
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Yeah I had a nightly build for 1.1.4 from last week that had some bad
pie in it I think. 1.1.4 proper fixed it thanks.
Mike
Nick S. wrote:
from org.jruby.util.Dir:799:in `newStringFromUTF8'
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
On Mon, Oct 27, 2008 at 5:49 PM, Mike H. [email protected]
wrote:
BUILD FAILED
/home/mike/projects/jruby-rack/nbproject/build-impl.xml:545: The following
error occurred while executing this line:
/home/mike/projects/jruby-rack/nbproject/build-impl.xml:203: The
for must include junit.jar if not in Ant’s own classpath
If you tell me how to build it, I can document it in the JRuby wiki 
Sorry that I don’t have a trunk snapshot yet. Build instructions are
here:
http://wiki.jruby.org/wiki/JRuby_Rack#Building
JRuby 1.1.4 has a version of RubyGems that makes it a pain to install
buildr, so I’d suggest downloading the all-in-one jruby-buildr
package. That’s what I’m using to build JRuby-Rack right now.
/Nick
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Hey Nick - so would you recommend running off trunk for now?
I tried to find a snapshot to download, but didn’t find one.
I looked here:
http://www.projectkenai.com/projects/jruby-rack/downloads
I tried to build it, but got this error (even though Ant thinks it has
JUnit):
BUILD FAILED
/home/mike/projects/jruby-rack/nbproject/build-impl.xml:545: The
following error occurred while executing this line:
/home/mike/projects/jruby-rack/nbproject/build-impl.xml:203: The
for must include junit.jar if not in Ant’s own
classpath
If you tell me how to build it, I can document it in the JRuby wiki
Mike
Mike H. wrote:
Well that explains a bunch, thanks.
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email