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
