[
https://issues.apache.org/jira/browse/HTTPCLIENT-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14996460#comment-14996460
]
Jochen Kemnade edited comment on HTTPCLIENT-1216 at 11/9/15 12:43 PM:
----------------------------------------------------------------------
The problem is that ThreadLocal is subclassed. That leads to a whole
ClassLoader structure being leaked. The attached patch fixes the issue by
initializing the TheadLocal's value on demand.
This does affect recent versions (such as 4.5.1) by the way.
was (Author: jkemnade):
The problem is that ThreadLocal is subclassed. That leads to a whole
ClassLoader structure being leaked. The attached patch fixes the issue by
initializing the TheadLocal's value on demand.
> org.apache.http.impl.cookie.DateUtils creates but doesn't cleanup a
> ThreadLocal instance
> ----------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1216
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1216
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.2.1
> Environment: Window 7 Pro SP1 64bit, Tomcat 7.0.25
> Reporter: Scott Patterson
> Priority: Minor
> Fix For: 4.2.2, 4.3 Alpha1
>
> Attachments:
> 0001-HTTPCLIENT-1216-avoid-subclassing-ThreadLocal-to-pre.patch
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
