"JRuby runtime management and pooling is done automatically by the
framework. In the case of Rails, runtimes are pooled. For Merb and other
Rack applications, a single runtime is created and shared for every
request. "
I just want to make sure that I understand this statement and its
implications for a Merb app.
Does this mean that a new Java thread is spun up for each request into
the Merb app.?
When do those threads go away?
What would it take to allow for JRuby runtime pooling for Merb apps. as
is (apparently) already done for Rails apps.?
No. Since Merb is supposed to be safe to use in the presence of
multiple threads, a single JRuby runtime (with the Merb application
loaded in it) is used for all requests. No new threads are spawned
(modulo any that the appserver might spin up to handle the request).
implications for a Merb app.
Does this mean that a new Java thread is spun up for each request into the
Merb app.?
When do those threads go away?
No. Since Merb is supposed to be safe to use in the presence of
multiple threads, a single JRuby runtime (with the Merb application
loaded in it) is used for all requests. No new threads are spawned
(modulo any that the appserver might spin up to handle the request)
So, just to be clear - does the single JRuby runtime (actually a Java
thread) act as a dispatch thread which then hands off actual work to
another JRuby runtime (actually a Java thread)? Embedded in this
statement is the assumption that Merb has one dispatch thread and uses
other threads to actually do work - is that correct?
Bottom line, I want to be confident that running Merb within a JRuby
context will give me the same “less-blocking-than-Rails” behavior that I
would get if I were running it as pure Ruby. Will that be the case?
So, just to be clear - does the single JRuby runtime (actually a Java
thread) act as a dispatch thread which then hands off actual work to another
JRuby runtime (actually a Java thread)? Embedded in this statement is the
assumption that Merb has one dispatch thread and uses other threads to
actually do work - is that correct?
It all runs on the same thread. The app server’s request handling
thread gets a reference to the single JRuby runtime and runs the merb
request in it. No child threads or worker threads are involved, unless
you’re creating some in application code.
Bottom line, I want to be confident that running Merb within a JRuby context
will give me the same “less-blocking-than-Rails” behavior that I would get
if I were running it as pure Ruby. Will that be the case?
Same, but probably better considering that JRuby’s native threads.
No. Multiple threads can execute code in the single runtime
concurrently. You should be able to achieve better concurrency on file
uploads with Merb, even in the JRuby/JEE container world.
“Multiple threads” = multiple green threads managed by Merb code within
the single JRuby runtime.
“runtime” = one Java thread running within the JEE container.
So doesn’t this throttle the throughput of the Merb app. since all requests
are being run in one JRuby runtime (Java thread)?
The reason that we want to use Merb is to get more concurrency on file
uploads. Don’t we lose that if every request is being run in one JRuby
runtime?
No. Multiple threads can execute code in the single runtime
concurrently. You should be able to achieve better concurrency on file
uploads with Merb, even in the JRuby/JEE container world.
“Multiple threads” = multiple green threads managed by Merb code within the
single JRuby runtime.
No, “multiple threads” = multiple java/native threads. Merb code does
not manage this at all. Merb is just a request handling framework, not
a server.
“runtime” = one Java thread running within the JEE container.
One Java object that encapsulates the runtime code and behavior to
execute that code. A thread comes into play when you want to execute
that code, but has nothing to do with the runtime itself.
OK, I’m getting closer to understanding. We may be talking past each
other here, unfortunately.
There is 1 Merb = 1 runtime = 1 request dispatcher (or is this 1 Rack =
1 runtime = 1 request dispatcher?). I’m not sure I get what you mean by
“runtime” when you talk about it like it isn’t actual code that is
running. Isn’t a JRuby “runtime” a Java thread that behaves just like a
Ruby process does in the non-JRuby world?
There are N Java threads to handle work.
So, is N = the # of concurrent requests, then, by default?
Also, there is part of Merb that actually executes my controller code,
correct? So is there a “dispatcher” portion of Merb that runs in one
thread as opposed to another portion of Merb that is executed in a
separate thread (to actually service a request)? (again, maybe the
dispatcher piece is what Rack is?).
Not trying to be dense, just trying to be precise.
Thanks,
Wes
Nick S. wrote:
“runtime” = one Java thread running within the JEE container.
1 runtime = a single JRuby/Ruby runtime instance. As requests comes
in Merb will spawn Ruby Threads to handle each request. In JRuby a
Ruby thread is a native Java thread. So a single JRuby runtime and n
1 Java threads can handle all n concurrent merb requests. Since
these threads are not green threads (like C Ruby) in theory all
requests should happen concurrently in JRuby.
RoR:
n JRuby/Ruby runtimes = n listeners. A single Ruby runtime can only
handle a single incoming request. So n JRoR jruby instances need to
be started to handle n incoming requests.
Does anyone understand the role of the Global Interpreter Lock in the
performance of multiple native (Java) threads accessing a single JRuby
interpreter?
Thanks for the clear and succinct explanation. I realize now that when
we say runtime, we mean the JRuby Runtime object which encapsulates a
running Ruby interpreter instance. I keep jumping to the actual running
implementation of same. So…
What runs the JRuby runtime instance? I was under the impression that
that was also a Java thread. Is that correct?
Thanks,
Wes
Thomas E Enebo wrote:
OK, I’m getting closer to understanding. We may be talking past each other
So, is N = the # of concurrent requests, then, by default?
Wes
that code, but has nothing to do with the runtime itself.
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.