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
