On 18/08/2011 19:03, Dan Armbrust wrote:
> So, yesterday, I finally start working on upgrading on old application
> set to a current 6 release of Tomcat.
> 
> (Sigh, behind the truck already, seeing the announcement of the next
> version today bad timing by me...  beside the point)
> 
> Some of my web applications are using JFreeChart to generate images.
> Even though I'm using the -Djava.awt.headless=true flag, Tomcat is
> still telling this upon shutdown:
> 
> SEVERE: The web application [/ap] appears to have started a thread
> named [AWT-Windows] but has failed to stop it. This is very likely to
> create a memory leak.
> 
> How does one handle this properly?  It isn't a critical issue for me,
> since we never undeploy / redeploy anyway, without restarting the
> entire server.
> 
> But now it is just annoying me.  Someone must have had to deal with
> this before?  I can't figure out how I can either prevent the JVM from
> creating this thread, or how to get the JVM to let the thread end.

I suspect neither of those is an option. However, what you can probably
do (once you figure out which call is triggering the creation of this
thread) is something along the lines of this:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java?view=markup

> I haven't dug for it yet, but I assume there is a switch I can use to
> shut off the memory detect warnings?

You can disable log messages for that class (not something I'd
recommend) but you can't disable the memory leak checks. There is an
outstanding enhancement request to skip the warnings in situations where
they (arguably) can be safely ignored -
https://issues.apache.org/bugzilla/show_bug.cgi?id=50175 - although the
embedded vs. standalone point is a valid one that will need some careful
thought to ensure the right solution is implemented.

> (If I can't figure out how to
> fix all my issues)  I can't ship code to the customers that logs
> "SEVERE" errors on shutdown.

All the leaks should be fixable / possible to workaround.

Mark

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

Reply via email to