Yep, and a PoolingApplicationRackFactory xD, I'm starting to understand the code a little bit more.
On Fri, Jul 31, 2009 at 6:07 PM, Bob McWhirter <[email protected]> wrote: > I think there *is* (or was) a SharedRackApplicationPool, which cached the > rack apps. > > I think that pool is used if min=max=1. > > It's been months since I looked at jruby-rack, though, so I could easily be > wrong. > > -Bob > > > On Jul 31, 2009, at 11:47 AM, Charles Oliver Nutter wrote: > > I think a modified version that actually caches initialized *rack >> apps* rather than simple initialized runtimes would probably solve >> this. >> >> At some point we're also going to want to unify rack apps and servlets >> a bit more closely so that they're mostly the same thing. That may >> depend on Java integration allowing Java strings to pass back and >> forth freely... >> >> Give it another look, see if you can come up with something. >> >> On Fri, Jul 31, 2009 at 10:33 AM, David >> Calavera<[email protected]> wrote: >> >>> That's right. I'm also unfamiliar with the code XD and actually there are >>> a >>> lot of things I don't understand. >>> I don't see that runtime's pool, there is a method called newRuntime() in >>> the class DefaultRackApplicationFactory that created a new runtime for >>> each >>> request. >>> >>> On Fri, Jul 31, 2009 at 4:46 PM, Charles Oliver Nutter < >>> [email protected]> >>> wrote: >>> >>>> >>>> Nice, thanks! I've been sick all week so I haven't been able to >>>> concentrate on coding much...this is a great start. >>>> >>>> I do see one possible problem, though I may just be unfamiliar with >>>> the code...how does this handle multiple runtimes in use? I think one >>>> reason it may have recreated it every time is because it pulled a >>>> runtime from the pool and put it back every time. We could modify the >>>> pool to hold initialized apps or something, but I think what you have >>>> here would only work if a single runtime is acceptable. >>>> >>>> On Fri, Jul 31, 2009 at 5:33 AM, David Calavera< >>>> [email protected]> >>>> wrote: >>>> >>>>> I'm starting to include these advice in patches, here is the first one: >>>>> >>>>> http://kenai.com/jira/browse/JRUBY_RACK-20 >>>>> >>>>> Btw, I also get similar errors with maven, using rake directly seems to >>>>> work >>>>> fine. >>>>> >>>>> On Fri, Jul 31, 2009 at 3:46 AM, Charles Oliver Nutter >>>>> <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> I'm looking through jruby-rack for the first time in a long time, and >>>>>> I think there's some room for a refactoring and cleanup that might >>>>>> improve performance quite a bit. Here's my notes: >>>>>> >>>>>> * For every request, it does an evalScriptlet to load the rack servlet >>>>>> wrapping stuff and prepare a rack servlet handler. This would probably >>>>>> be more efficient if we only did this load logic once and just >>>>>> constructed a new app/handler directly rather than through >>>>>> evalScriptlet and load. >>>>>> * Repeatedly access modules, etc, could be cached if we had an >>>>>> additional wrapper layer around each Ruby instance in memory. Then we >>>>>> could, for example, cache a reference to Rack::Handler::Servlet and >>>>>> construct it directly. >>>>>> * This logic is using Java integration quite a bit. We may want to >>>>>> used this to tune JI logic/performance, especially wrt the interface >>>>>> implementation for e.g. RackResponse and RackApplication. We may be >>>>>> better served by stuffing all the data from the Java side into the >>>>>> Ruby objects directly, rather than depending as much on JI to populate >>>>>> them. Of course, we want JI to work well enough that this sort of case >>>>>> *does* work fine. >>>>>> >>>>>> I'm having some trouble getting it to build locally: >>>>>> >>>>>> [INFO] Building JRuby-Rack >>>>>> [INFO] task-segment: [install] >>>>>> [INFO] >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> [INFO] [jruby-rake:rake {execution: unpack-gem}] >>>>>> [INFO] rake already installed >>>>>> [WARNING] /usr/bin/rake:19: undefined method `bin_path' for Gem:Module >>>>>> (NoMethodError) >>>>>> [INFO] >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> [ERROR] FATAL ERROR >>>>>> [INFO] >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> [INFO] Java returned: 1 >>>>>> [INFO] >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> [INFO] Trace >>>>>> Java returned: 1 >>>>>> at org.apache.tools.ant.taskdefs.Java.execute(Java.java:86) >>>>>> at org.jruby.maven.RakeMojo.execute(RakeMojo.java:62) >>>>>> at >>>>>> >>>>>> >>>>>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) >>>>>> ... >>>>>> >>>>>> If I can get it to build I'll try to make some of these improvements. >>>>>> For now I will move on to DataMapper/DataObjects and try to do some >>>>>> optimization passes there. >>>>>> >>>>>> - Charlie >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe from this list, please visit: >>>>>> >>>>>> http://xircles.codehaus.org/manage_email >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> David Calavera >>>>> http://www.thinkincode.net >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this list, please visit: >>>> >>>> http://xircles.codehaus.org/manage_email >>>> >>>> >>>> >>> >>> >>> -- >>> David Calavera >>> http://www.thinkincode.net >>> >>> >> --------------------------------------------------------------------- >> 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 > > > -- David Calavera http://www.thinkincode.net
