Forum: JRuby best approach for multiple rails applications inside Tomcat?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
E2489efc6ec10ec818b71965909ea109?d=identicon&s=25 Jin Lee (Guest)
on 2009-01-26 21:17
(Received via mailing list)
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
526d60de6472502bb570a9df2842b33b?d=identicon&s=25 Nick Sieger (Guest)
on 2009-01-27 06:31
(Received via mailing list)
On Mon, Jan 26, 2009 at 2:16 PM, Jin Lee <jinslee@gmail.com> 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
A4763c4be7554c56fd0905fc57ede474?d=identicon&s=25 Mwadhera Mike (mwadhera)
on 2009-01-27 07:36
(Received via mailing list)
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 Sieger <nicksieger@gmail.com>
wrote:
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>



--
Best,

Mike Wadhera
http://metasaur.us

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-01-27 16:28
(Received via mailing list)
Mike Wadhera 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
E2489efc6ec10ec818b71965909ea109?d=identicon&s=25 Jin Lee (Guest)
on 2009-01-27 17:50
(Received via mailing list)
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 Nutter
<charles.nutter@sun.com> 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
F01ce529e34138c62cd9af4e36ac8921?d=identicon&s=25 Tommy M. McGuire (Guest)
on 2009-01-29 20:25
(Received via mailing list)
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 Wadhera 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
mcguire@crsr.net

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
This topic is locked and can not be replied to.