You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by "Kyrill Alyoshin (JIRA)" <hi...@jakarta.apache.org> on 2005/12/06 00:30:08 UTC
[jira] Created: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
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
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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "Kyrill Alyoshin (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=comments#action_12360104 ]
Kyrill Alyoshin commented on HIVEMIND-161:
------------------------------------------
Adding "_storage.set(null);" to the end of fireThreadCleanup() fixes the problem.
It was a pleasure to watch how that classloader got garbage collected (along with 20M of memory it was holding) after a hot-reload. :-)
Now we need to figure out how to deal with the broken tests. It seems like the second test is really not needed.
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "Kyrill Alyoshin (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=comments#action_12359599 ]
Kyrill Alyoshin commented on HIVEMIND-161:
------------------------------------------
I agree, one really cannot verify garbage collection by a unit test since it is not deterministic. :-)
What I meant was a test like:
assertNull("evenListenerList removed from ThreadLocal",obj_instance.getStorage().get());
but that would require an API change since "_storage" is private and mutable. I think adding getStorage() is a good idea, since circumstances can be imagined where a direct cleanup of a ThreadLocal variable may be needed.
Please email me you hivemind.jar with the fix (click on my username to get the email :-)), and I will test it asap.
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "Kyrill Alyoshin (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=comments#action_12359636 ]
Kyrill Alyoshin commented on HIVEMIND-161:
------------------------------------------
But such test would pass even with current code. I don't see where removal of ThreadLocal value is tested/accounted for? Am I missing something?
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Resolved: (HIVEMIND-161) ThreadLocal object is never removed
in ThreadEventNotifierImpl and holds the classloader
Posted by "Knut Wannheden (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=all ]
Knut Wannheden resolved HIVEMIND-161.
-------------------------------------
Fix Version/s: 1.1.1
Resolution: Fixed
> 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
> Issue Type: Bug
> Components: framework
> Affects Versions: 1.1
> Environment: Tomcat 5.5.12, J2SE 1.6 Mustang build 62, Win XP SP2
> Reporter: Kyrill Alyoshin
> Assigned To: Howard M. Lewis Ship
> Priority: Critical
> Fix For: 1.1.1
>
> 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
[jira] Commented: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "James Carman (JIRA)" <hi...@jakarta.apache.org>.
[ 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Updated: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "Kyrill Alyoshin (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=all ]
Kyrill Alyoshin updated HIVEMIND-161:
-------------------------------------
Attachment: hivemind-threadlocals.pdf
Here is a snapshot from YourKit taken on a classloader of a fully unloaded application.
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "James Carman (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=comments#action_12359638 ]
James Carman commented on HIVEMIND-161:
---------------------------------------
The current code would fail at step 5. The listener would be notified twice. Even after thread cleanup. But, with the new change, it wouldn't.
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "James Carman (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=comments#action_12359376 ]
James Carman commented on HIVEMIND-161:
---------------------------------------
My fix breaks the testConcur() method which does the following:
public void testConcur()
{
ThreadEventNotifier n = new ThreadEventNotifierImpl();
Listener l1 = new Listener();
ConcurMod l2 = new ConcurMod(n);
Listener l3 = new Listener();
n.addThreadCleanupListener(l1);
n.addThreadCleanupListener(l2);
n.addThreadCleanupListener(l3);
n.fireThreadCleanup();
assertEquals(true, l1._cleanup);
assertEquals(true, l2._cleanup);
assertEquals(true, l3._cleanup);
l1._cleanup = false;
l2._cleanup = false;
l3._cleanup = false;
n.fireThreadCleanup();
assertEquals(true, l1._cleanup); // Fails here!
assertEquals(false, l2._cleanup);
assertEquals(true, l3._cleanup);
}
Why would we want to call fireThreadCleanup() twice within the same thread? Is that a real possibility/use case? My fix basically clears the listener list out of the thread local variable inside fireThreadCleanup() and therefore, it can't cleanup those listeners the second time.
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "James Carman (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=comments#action_12359618 ]
James Carman commented on HIVEMIND-161:
---------------------------------------
How about this...
1. Add a thread cleanup listener.
2. Fire thread cleanup.
3. Verify that the listener is called.
4. Fire thread cleanup again.
5. Verify that the thread cleanup listener is not notified.
6. Re-register the thread cleanup listener.
7. Fire thread cleanup again.
8. Verify that the listener is called.
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "James Carman (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=comments#action_12359598 ]
James Carman commented on HIVEMIND-161:
---------------------------------------
Well, it'll be hard to verify via a unit test that the classloader can be garbage collected. However, if you would try applying my change (that one line), recompiling HM and using it in your environment to verify that the memory leak is not there anymore, I would be happy to create a few more "unit-like" tests for this. And, no problem on the response time.
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "James Carman (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=comments#action_12359375 ]
James Carman commented on HIVEMIND-161:
---------------------------------------
I was wondering what was causing these memory leaks. I was playing around with Tapestry 4.0 over the weekend and after a few redeploys in IntelliJ IDEA, it would run out of memory! So, do you think just clearing the thread-local variable in fireThreadCleanup() should do it?
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Assigned: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "Howard M. Lewis Ship (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=all ]
Howard M. Lewis Ship reassigned HIVEMIND-161:
---------------------------------------------
Assign To: Howard M. Lewis Ship
> 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
> Assignee: Howard M. Lewis Ship
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "James Carman (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=comments#action_12359408 ]
James Carman commented on HIVEMIND-161:
---------------------------------------
Oh, I could probably move the _storage.set( null ) down after the while loop.
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "Howard M. Lewis Ship (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=comments#action_12360105 ]
Howard M. Lewis Ship commented on HIVEMIND-161:
-----------------------------------------------
I think you have definately uncovered a minor design flaw here.
The hivemind.ThreadEventNotifier service was designed so that service implementations, or other objects, could register and unregister at will.
If you check the code, the majority of objects that register with the notifier will unregister themselves inside threadDidCleanup().
However, you are absolutely correct that there's nothing to discard a thread's event locals after the thread is done or the registry shutdown. This is one of those situations where an application server can provide a level of lifecycle support that a framework, operating generically as HiveMind does, can not. Thus the need for Registry methods setupThread() and cleanupThread(). In fact, the HiveMind servlet exists primarily to invoke those two methods.
So I believe we do need a change in design direction, to discard all ThreadLocals at the end of the current request. This includes the list of ThreadCleanupListener, but any others we're using within the code.
One of the nice things about HiveMind is that, once we properly handle this, user code won't be suspectible to the same problem.
A careful review of this code, as well as any other code that makes use of a ThreadLocal is needed.
I'll need to look at the unit test, to see if the changes you've mentioned are correct; I suspect they are. Great find!
I suspect there will be a HiveMind 1.1.1, and a Tapestry 4.0.1 to make use of it.
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "Kyrill Alyoshin (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=comments#action_12359544 ]
Kyrill Alyoshin commented on HIVEMIND-161:
------------------------------------------
Yes, moving it below the while loop should cleanup the ThreadLocal. I wonder if Tapestry 4 is set up to call fireThreadCleanup() when ApplicationServlet stops, since only then the solution will be complete.
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "Kyrill Alyoshin (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=comments#action_12359646 ]
Kyrill Alyoshin commented on HIVEMIND-161:
------------------------------------------
Yes, I see, that would do the trick. But we'd still need the test for this bug, I think.
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "Kyrill Alyoshin (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=comments#action_12359596 ]
Kyrill Alyoshin commented on HIVEMIND-161:
------------------------------------------
Probably a very good idea is to write a quick test for this change as well.
Jim, I should also say that I really appreciate your quick response to this issue.
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "Kyrill Alyoshin (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=comments#action_12359615 ]
Kyrill Alyoshin commented on HIVEMIND-161:
------------------------------------------
Or if we don't want to expose storage directly, a monitoring method could be added... Something along the lines:
public boolean isThreadLocalCleanedUp() {
return _storage.get() == null;
}
This way you could use it to write the test and avoid exposign mutable "_storage".
the test then would look like:
assertFalse("storage removed from ThreadLocal", obj.isThreadLocalCleanedUp());
A good regression test to have.
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "Kyrill Alyoshin (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=comments#action_12359377 ]
Kyrill Alyoshin commented on HIVEMIND-161:
------------------------------------------
It'd be nice to know what your fix was, Carman. :-)
Anyway, the point is that there is a private ThreadLocal variable (in particular "_storage" variable in ThreadEventNotifierImpl) that is never "cleaned up" in that object. (There is simply nothing that does "_storage.set(null);" in that class); therefore, this Thread (i.e. an object loaded by System classloader) will always contain strong references to objects stored in "_storage" and, as a result, WebappClassLoader will never be garbage collected along with everything it points to.
Howard said he's gonna look into it in a couple of days once he settles in his new home on the west coast.
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "James Carman (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=comments#action_12359567 ]
James Carman commented on HIVEMIND-161:
---------------------------------------
I'm sure Tapestry is set up to call Registry.cleanupThread() once the response is finished being written to the client. HiveMind has a built-in servlet filter for this, but I believe the HiveMind support in Tapestry is done a bit differently. Does anyone have any good reason why the test case insists that fireThreadCleanup() would be called more than once for a particular thread? If not, I'll change the test case and integrate my changes. Howard?
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-161) ThreadLocal object is never removed in ThreadEventNotifierImpl and holds the classloader
Posted by "Kyrill Alyoshin (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-161?page=comments#action_12359616 ]
Kyrill Alyoshin commented on HIVEMIND-161:
------------------------------------------
I meant assertTrue(), not assertFalse, of course.
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org