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
