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
