Best approach for multiple rails applications inside Tomcat?

HI all -

Today I am bringing up my second rails application inside the same
Tomcat installation. What is the best approach for this task? Since I
am using warbler, should I remove jruby-complete in each local war and
put the jruby-complete jar in common/lib? What about the jruby-rack
jar as well?

Thanks for your help -

Jin


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On Mon, Jan 26, 2009 at 2:16 PM, Jin L. [email protected] wrote:

HI all -

Today I am bringing up my second rails application inside the same
Tomcat installation. What is the best approach for this task? Since I
am using warbler, should I remove jruby-complete in each local war and
put the jruby-complete jar in common/lib? What about the jruby-rack
jar as well?

Thanks for your help -

You can certainly take that approach if you don’t like the idea of
multiple copies of the jars inside each war file – it should work
fine as far as I know.

If memory is not a major concern, I wouldn’t worry too much about the
duplication of 10-15MB per web application, however. You might find
that the flexibility of maintaining separate versions of JRuby and
JRuby-Rack per webapp could be an advantage.

/Nick


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

We (Involver.com) deploy multiple rack applications and package jruby
& rack in our app server’s (GF) lib. Works well for us. Adds a little
more overhead when provisioning a new app server, but we prefer the
single copy of these core libraries loading only once at GF startup.
Also, I have no hard numbers on this, but I think app deploys are a
bit quicker with this technique as there is less moving parts in each
push.

On Mon, Jan 26, 2009 at 9:30 PM, Nick S. [email protected]
wrote:


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


Best,

Mike W.
http://metasaur.us


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Mike W. wrote:

We (Involver.com) deploy multiple rack applications and package jruby
& rack in our app server’s (GF) lib. Works well for us. Adds a little
more overhead when provisioning a new app server, but we prefer the
single copy of these core libraries loading only once at GF startup.
Also, I have no hard numbers on this, but I think app deploys are a
bit quicker with this technique as there is less moving parts in each
push.

That’s probaby true; the extra copy of JRuby for every app does require
the server to load more stuff per app and the JVM to load and verify the
classes involved for each app. It also puts extra memory pressure on the
“perm gen” in Sun JDK. So if you know you’re only ever going to use a
single JRuby version putting it in the app server’s lib might work well.

We will continue to try to shrink the JRuby jar itself, of course.

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Just FYI - I went ahead and deployed with a jruby in each war, not for
any particular reason, just because it was the most convenient. There
is an increase in memory usage but the overhead is not bad at all.
Plus, like Nick said, I like having the ability to control which jruby
version is in each app, which might be useful in the future.

Thanks for your feedback all -

Jin

On Tue, Jan 27, 2009 at 7:28 AM, Charles Oliver N.
[email protected] wrote:

That’s probaby true; the extra copy of JRuby for every app does require the
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

We’ve been using a separate jruby bundle with two applications
(currently, two
versions each of two applications) with the SpringSource dm server. It
certainly made the 1.1.5 → 1.1.6 upgrade a breeze.

Mike W. wrote:

We (Involver.com) deploy multiple rack applications and package jruby
& rack in our app server’s (GF) lib. Works well for us. Adds a little
more overhead when provisioning a new app server, but we prefer the
single copy of these core libraries loading only once at GF startup.
Also, I have no hard numbers on this, but I think app deploys are a
bit quicker with this technique as there is less moving parts in each
push.


Tommy M. McGuire
[email protected]


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email