https://bz.apache.org/bugzilla/show_bug.cgi?id=59138
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
OS| |All
Resolution|--- |INVALID
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
The situation described is a memory leak.
The problem is not the value but the anonymous class. It is loaded by the web
application class loader. That pins the web application class loader in memory
creating the memory leak.
The Tomcat code has been carefully written to avoid false positives. Tomcat
checks the implementing class of the key and the value and if either of them
have been loaded by the web application class loader then there is a memory
leak and it will be reported.
The current code errs on the side of false negatives. It is possible to
construct a memory leak that this code won't spot but, given how the code is
written, a false positive could only occur as a result of a bug. There has been
no such bug reported in the previous 5+ years that this code has been in place
in this form (I could have gone back further but 5 years seem long enough to
make my point).
If you see a warning, it is extremely likely that you have a memory leak.
If a 3rd-party library believes Tomcat is falsely reporting a false positive
for a ThreadLocal that that library creates and it has been checked with a
profiler that the implementing classes for both the key and the value have not
been loaded by the web application class loader (or a child class loader) then
I'll happily take a look and fix any bug. But experience tells me that it is
far more likely that the library does have a memory leak.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
