https://bz.apache.org/bugzilla/show_bug.cgi?id=59138
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |---
Status|RESOLVED |REOPENED
--- Comment #5 from Mark Thomas <ma...@apache.org> ---
I still had the memory dump so I was able to confirm that the key was strongly
reachable.
There were a number of GC roots listed of which one was the ThreadLocal map.
Digging into the GC roots found the problem. Somehow (and I haven't figured out
how to reproduce this yet) one of the profiler's classes was loaded by the
WebappClassLoader. That was pinning the class loader in memory hence the
ThreadLocal key was strongly held.
I'm as sure as I can be that this is what I was seeing previously. If I run the
test all the way through then attach the profiler (rather than attaching at the
start so I can monitor what is going on) then the key is not strongly held, the
garbage collector does it's job after which the class loader is released.
I am therefore re-opening this issue.
At first glance, the fix appears to be as simple as removing the class loader
check for the ThreadLocal key.
However, we have had issues reported where objects being retained after web
application stop until the next GC has been sufficient to cause problems. If
memory serves me correctly, those were all JDBC related. In this case, I don't
think that will be an issue. Currently, ThreadLocal issues are cleaned up by
renewing the thread pool and that won't change with the proposed change. All
that changes is that keys won't trigger the warning messages.
We could log issues with keys at debug level on the grounds that users might
find it useful. That will complicate the code though. I'm not sure that is
worth doing. I'll think about it over night and come back to this tomorrow.
--
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
