tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Best practices for shared classloader use?
Date Tue, 04 Jun 2013 18:06:36 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Daniel,

On 6/4/13 12:44 PM, Daniel Mikusa wrote:
> On Jun 4, 2013, at 11:36 AM, Don Asper <Don.Asper@sas.com> wrote:
> 
>> I am considering using the Tomcat 7 shared classloader to reduce
>> the memory footprint of my web apps.
> 
> IMHO, don't do this unless…
> 
> 1.) You are very, very sure what you are doing 2.) You've analyzed
> the memory savings that you'll achieve by doing this and you are
> sure that it is significant compared to the cost of your time if
> you need to debug a problem.

+1

You're only saving the cost of classes actually loaded, and then only
the memory used by the java.lang.Class files (plus some housekeeping
for them). It's not like you are going to save GiBs of heap space by
using a shared ClassLoader.

>> But, I'm afraid that loading my application jar files into a 
>> single classloader will cause lots of problems. I'm aware that
>> the shared classpath should not specify multiple versions of the
>> same class. But I suspect, for example, that classes that have
>> static properties must not be shared. Am I correct in thinking
>> this? Are there other problems that I should anticipate?
>> Thanks!>
> 
> In my experience, errors of this nature are typically subtle and 
> difficult to debug, another reason why I'd recommend against this.
> 
> My personal favorite error is the ClassCastExceptions that say 
> something like "cannot cast classX to classX" that occurs when
> classX from one class loader is attempted to be cast to classX from
> another class loader. There are others, you can probably find some
> more good examples by looking back through the list archives.
> 
> My advice is to follow the kiss principle and just put your JAR 
> files in with your web application.

+1

You also get the flexibility of being able to use different versions
with different webapps ... plus no nasty surprises when some data ends
up being shared and shouldn't be.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRriyrAAoJEBzwKT+lPKRYNtIQAKsecIe7MnzD5M4Ep25oFP8f
B8k+WHOEeDOe6T36j7Dxx+2IGwBwBIYcoQ0pQ4r0Rs2XEAtTJgIWVhwRtvxtoXy0
aDowU6NCoZVqQXo99ansTjFjyUm4eRGWKvG5vNSyuT8flOGCEgYHmr5m0hQj3CjE
NMKAAkk2Yv1XuV7SQoGiA4DxjAtXPGcIwMR0zjdsbb8xiayiFip0qYC83t9EaKW7
Ng+GtmjhtFGS0YM4OiQmsNBuTGf/KNr//9a4Fdf+XpZvwto40A6JB3Zn3XcVk6A8
Gs3pfkjWF3+3tW08l3lekEdVs9LnzDYqaCSB4KMhoFcZx9a0Mz5I/plprfblXXaR
t7PwCmjSLKg4TjYd1Gmd9jrKZkusTk8KxSdVm7arQEzCx+L3kM8qzJ3gqGcmx0jk
m1z7q0rNde/B2QbwUsoep1I8gI8owful5LgYX78xfYZH1Axklyn6F9zyxvOQ0Dj+
K2941EVoKcu43RCkrDzV/jE6aDUcbd4yIbBI0oNJbODoFCJi2qtIqzaUq0YzG1qF
KlU5A7m6ZEH08RM8VkA3QtPA6u93LXp2aaFlvxpUlPi6Yu0xVFCJcFvQku9ZSO0Y
RbRsU6YlCCq1qYISpJbsKohOgOmNSQJqbBWyi+1xv+//fJxwAVkl6ki/FXqdvIay
VX0ZIm0tZZweilyddbDk
=fPda
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message