[
http://issues.apache.org/jira/browse/HIVEMIND-161?page=comments#action_12359407
]
James Carman commented on HIVEMIND-161:
---------------------------------------
Here's what I have done in the code (comment is on the line I added):
public void fireThreadCleanup()
{
// Here's where we need the CursorableLinkedList since listeners
// are free to unregister as listeners from threadDidCleanup() and
// we need to avoid concurrent modification errors.
EventListenerList list = (EventListenerList) _storage.get();
if (list == null)
return;
_storage.set( null ); // Allow garbage collection (HIVEMIND-161)
Iterator i = list.getListeners();
while (i.hasNext())
{
ThreadCleanupListener listener = (ThreadCleanupListener) i.next();
// Each listener may decide to remove itself; that's OK,
// EventListenerList handles that kind of concurrent
modification
// well.
listener.threadDidCleanup();
}
}
My main question is whether we would ever want to call fireThreadCleanup() more
than once on a thread. That seems a bit odd to me. Why does the test case
insist that it is allowed and the listeners are notified each time. That would
mean that the listeners have to hang around perpetually since
fireThreadCleanup() could be called any number of times. I don't think that's
right. Howard, you probably wrote this test case. Do you recall why we would
want to be able to call fireThreadCleanup() more than once?
> ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the
> classloader
> ----------------------------------------------------------------------------------------
>
> Key: HIVEMIND-161
> URL: http://issues.apache.org/jira/browse/HIVEMIND-161
> Project: HiveMind
> Type: Bug
> Components: framework
> Versions: 1.1
> Environment: Tomcat 5.5.12, J2SE 1.6 Mustang build 62, Win XP SP2
> Reporter: Kyrill Alyoshin
> Priority: Critical
> Attachments: hivemind-threadlocals.pdf
>
> The following prevents the web application classloader from being garbage
> collected on hot redeploys of web applications.
> Please note that the issue is present on J2SE 1.5 as well. I use 1.6 only
> because it has far better support for JVMTI and as such the issue was easy to
> discover with YourKit profiler. Here it is:
> 1. org.apache.hivemind.service.impl.ThreadEventNotifierImpl puts
> EventListenerList ("list" variable) on its private ThreadLocal "_storage"
> variable in addThreadCleanupListener method.
> 2. No where in that class does the actual list gets removed from ThreadLocal.
> Thus, the WebappClassLoader cannot be garbage collected because one of the
> object that it loaded (i.e. EventListenerList) is strongly referenced by live
> threads in the container, which leads to huge memory leaks on hot-redeploys.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.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]
