Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
4.2.1
-
None
-
Window 7 Pro SP1 64bit, Tomcat 7.0.25
Description
I have a WebApp running in Tomcat 7.0.25 that includes httpcore-4.1.2.jar and httpclient-4.1.2.jar. It makes heavy use of a org.apache.http.impl.client.cache.CachingHttpClient instance that is shared across multiple requests.
When shutting down tomcat a memory leak warning is logged.
May 11, 2012 11:16:42 AM org.apache.catalina.loader.WebappClassLoader checkThrea
dLocalMapForLeaks
SEVERE: The web application [/XXX] created a ThreadLocal with key of type [org.a
pache.http.impl.cookie.DateUtils$DateFormatHolder$1] (value [org.apache.http.imp
l.cookie.DateUtils$DateFormatHolder$1@50ff50ff]) and a value of type [java.lang.
ref.SoftReference] (value [java.lang.ref.SoftReference@51015101]) but failed to
remove it when the web application was stopped. Threads are going to be renewed
over time to try and avoid a probable memory leak.
Because the HttpClient instance is created by the WebAppClassloader for my app when processing a servlet request, the static DateUtils$DateFormatHolder's ThreadLocal instance ends up belonging to a thread from tomcat's request worker thread pool. When my app is destroyed by tomcat, the worker threads are resued by the servlet engine, thus leaking any ThreadLocal instances created in servlet requests.
I think it is a defect in the DateUtil API that it does not provide a means to cleanup internal ThreadLocal instances. There should be a "cleanup" method that internally invokes ThreadLocale.remove() on the DateUtils.DateFormatHolder.THREADLOCAL_FORMATS object.
Attachments
Attachments
Issue Links
- relates to
-
-
- Closed
-