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 06.08.2008 22:50
on 07.08.2008 03:44
On Wed, Aug 6, 2008 at 1:49 PM, Wes Gamble <weyus@att.net> 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
on 07.08.2008 18:31
Nick Sieger 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
on 07.08.2008 23:19
On Thu, Aug 7, 2008 at 9:30 AM, Wes Gamble <weyus@att.net> 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
on 07.08.2008 23:33
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 Sieger 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 07.08.2008 23:44
On Thu, Aug 7, 2008 at 2:33 PM, Wes Gamble <weyus@att.net> 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 08.08.2008 00:04
Nick Sieger 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 08.08.2008 00:15
On Thu, Aug 7, 2008 at 3:04 PM, Wes Gamble <weyus@att.net> 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
on 08.08.2008 00:30
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 Sieger 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
on 08.08.2008 03:28
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 Gamble <weyus@att.net> 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: enebo@acm.org , tom.enebo@gmail.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
on 08.08.2008 06:29
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
on 08.08.2008 19:53
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 Gamble <weyus@att.net> 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
on 14.08.2008 00:27
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 Jennings 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