JRuby runtime pooling for Rack question

From http://wiki.jruby.org/wiki/JRuby_Rack:

"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.?

Thanks,
Wes


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On Wed, Aug 6, 2008 at 1:49 PM, Wes G. [email protected] wrote:

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

/Nick


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Nick S. wrote:

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?

Thanks,
Wes


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

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?

Wes

Nick S. wrote:

thread gets a reference to the single JRuby runtime and runs the merb


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On Thu, Aug 7, 2008 at 9:30 AM, Wes G. [email protected] wrote:

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.

Cheers,
/Nick


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Nick S. wrote:

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.

Is this correct?

Wes


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On Thu, Aug 7, 2008 at 2:33 PM, Wes G. [email protected] wrote:

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.

/Nick


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On Thu, Aug 7, 2008 at 3:04 PM, Wes G. [email protected] wrote:

“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.

/Nick


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

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.

http://xircles.codehaus.org/manage_email

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Merb:

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.

A JRuby runtime == A C Ruby process

-Tom

On Thu, Aug 7, 2008 at 5:30 PM, Wes G. [email protected] wrote:

Thanks,

execute that code. A thread comes into play when you want to execute


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


Blog: http://www.bloglines.com/blog/ThomasEEnebo
Email: [email protected] , [email protected]


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Does anyone understand the role of the Global Interpreter Lock in the
performance of multiple native (Java) threads accessing a single JRuby
interpreter?

-Tyler

On Fri, Aug 8, 2008 at 12:29 AM, Wes G. [email protected] wrote:

Thanks,

these threads are not green threads (like C Ruby) in theory all
-Tom

“runtime” when you talk about it like it isn’t actual code that is
correct? So is there a “dispatcher” portion of Merb that runs in one
Wes

single JRuby runtime.

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

Which GIL are you talking about? I’m unaware of it’s existence? Could
you explain a bit more about what the GIL is and what your concern is?

Thanks,
Wes

Tyler J. wrote:

Thanks for the clear and succinct explanation. I realize now that when we
Thomas E Enebo wrote:

RoR:

process
thread

One Java object that encapsulates the runtime code and behavior to


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Tom,

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.

| Privacy Policy | Terms of Service | Remote Ruby Jobs