Yoav,
Thanks for the response. It helps me out significantly because I have already found that some of the code I wrote was definitely using static variables that could never go out of scope. I've removed those, but the problem persists.
I'm using log4j and Struts and your comment about LogManager#shutdown begs a question: Where in my code should I be calling the shutdown method? Is there some method in Tomcat that I need to override to call the shutdown method of each library I'm using? Or, should I be calling those methods by the end of each Struts Action#execute method? What about database connection pools? (I'm using OJB). I think that I want to maintain the pools even after the Action is executed so that the next database connection is relatively inexpensive. Where would I put the code to shutdown the pool only when a reload is happening?
Thanks for your wisdom,
-Anthony Carlos
On Sep 21, 2004, at 9:06 AM, Shapira, Yoav wrote:
Hi, Absolutely, the jars you used affect "reloadability". Two cases are the classics: - A library you use starts a non-daemon thread, and either doesn't close it or provides some sort of a shutdown method that you're not calling. This thread cannot be closed by Tomcat, so any of its resources (including its classloader by definition) cannot be recycled until the JVM is killed. - A library you use has classes that keep references to static variables that never go out of scope, meaning they can't be recycled, the classes with the references can't be recycled, and the classloader itself can't be recycled.
Two things are therefore encouraged: - Design your app / architecture such that the need for reloads in production is rare, - Find which libraries do either of the above things, notify the vendor, and get on their case to fix it.
There's also the obvious, ever-present advice, but it bears repeating: if a library you use provides methods to shutdown, always use them. For example, Log4j's LogManager#shutdown and Commons-Logging LogFactory#release/releaseAll methods. Both are rarely used ;(
Yoav Shapira Millennium Research Informatics
-----Original Message----- From: Anthony E. Carlos [mailto:[EMAIL PROTECTED] Sent: Monday, September 20, 2004 11:52 PM To: [EMAIL PROTECTED] Subject: Do the jars I use affect webapp reloadability?
Hello,
I'm experiencing a memory problem that is documented in http://jakarta.apache.org/tomcat/faq/deployment.html at the bottom. When I redeploy a web app, a 12MB chunk of memory gets taken by the JVM. After a few redeployments, I get an OutOfMemory error. The faq mentioned above blames it on the Classloader not being able to be recycled. I know that I can increase the size of the memory, but that isn't the real solution because eventually I'm going to have to restart Tomcat to reclaim the lost memory.
My question is, do the jars I'm using affect the reloadability of a web app so that the Classloader cannot be recycled? I suspect this because as soon as I add a few jars to my apps, I start experiencing this phenomenon. I have a suspicion that it is OJB or the Oracle JDBC drivers, but I don't have any empirical data. Do you know of any jars that specifically cause this? Is there anything that can be done to ensure that the Classloader can be recycled (thus allowing me to redeploy web apps without wasting memory)?
Thanks,
-Anthony Carlos
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
