[
https://issues.apache.org/jira/browse/HTTPCLIENT-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski updated HTTPCLIENT-1216:
------------------------------------------
Affects Version/s: (was: 4.1.3)
4.2.1
Fix Version/s: 4.2.2
Actually the ThreadLocal is contains a soft reference thus allowing the garbage
collector to dispose of its content when required. So, I do not think there is
a resource leak. I do not mind adding a method to explicitly unset the
ThreadLocal, though.
Oleg
> 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
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
