Comments in-line since people insist on top-posting.
Some at the end as well . . . .
On 1/17/2013 10:48 AM, Shanti Suresh wrote:
Hi Chuck, Dan,
Sometimes, sharing classes across applications may become necessary
though. We have a situation where a separate application and
associated webapp classloader is launched for each site in our
application. The reason this is happening is because things have
been setup differently internally - without going into too many
details. So, we ran into PermGen exhaustion issues. Putting all the
Fix your web application, fix your libraries, and don't use libraries
that cause PermGen leaks - they weren't properly designed for web
applications in the first place.
There are many good articles on PermGen leaks on the web, what causes
them, how to find them, and how to avoid them. Google is your friend.
libraries in $CATALINA_HOME/common/lib" and modifying the common
classloader in catalina.properties as follows, ensures that a single
copy of the classes get loaded and shared among all sites:
common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,${catalina.base}/common/lib/*.jar
We wanted to also put the libraries into a separate directory
called "common/" because we wanted to keep them separate from the
Tomcat-native libraries.
He may have a similar situation too; don't know.
That being said, I have one library used by some applications that
creates problems. It doesn't cause much of a leak, but over time it will
create an issue. Unless I rewrite the vendor's code (tempting) or use a
different library (also tempting), I'm stuck with this leak.
Probably the cleanest way to attack this problem (until you fix your
code), is to run out of $CATALINA_BASE. Leave a default Tomcat as
$CATALINA_HOME, and then put all of your misbehaving libraries in
$CATALINA_BASE/lib.
See RUNNING.txt for how this works. We use this method to load JDBC
drivers and mail.jar in certain instances of Tomcat, while leaving other
instances of Tomcat 'bare'.
This still creates a nightmare (in my opinion) for software release
management. You must ensure that all applications running on a
particular infected Tomcat use the same version of the libraries placed
in $CATALINA_BASE/lib.
This of course places the burden on operations and systems people rather
than on developers. My personal opinion is that badly behaved
applications should be taken care of by developers and not triaged by
the systems people. However, I'm a systems person so I'm probably a bit
biased in that regard.
Again - for PermGen leaks - fix your code.
Regards,
-Shanti
On Thu, Jan 17, 2013 at 10:58 AM, Daniel Mikusa <dmik...@vmware.com>
wrote:
On Jan 17, 2013, at 10:26 AM, Caldarale, Charles R wrote:
From: Narahari 'n' Savitha [mailto:savith...@gmail.com]
Subject: Re: common vs system vs shared class loaders
Sorry Dan but if I do what you are suggesting I will end up in
redundant jars all over the place and I dont want to do that.
That's an issue easily handled by a deployment script. You
really,
really, really do not want to share classes across webapps.
- Chuck
+1
Dan
Please folks, is not top-posting that difficult to understand? If you
top-post, then I have to scroll up and down the message to figure out
the context, and make sure that what I'm answering is:
a. The question being asked
b. Hasn't been answered in this fashion before
c. Fits all the constraints of the problem.
Doing so takes time. I participate here because I use Tomcat and hope to
contribute back to the community. Top-posting creates an additional
barrier which discourages contribution.
. . . . just my two cents.
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
