[jboss-jira] [JBoss JIRA] Created: (JGRP-755) ProtocolStack: verify that TimeScheduler gets garbage collected on redeployment

ProtocolStack: verify that TimeScheduler gets garbage collected on redeployment ------------------------------------------------------------------------------- Key: JGRP-755 URL: http://jira.jboss.com/jira/browse/JGRP-755 Project: JGroups Issue Type: Task Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.7 Attachments: ThreadLeakTest.java ProtocolStack hold a static ref to TimeScheduler, making the timer a JVM singleton. However, what happens if the channel is redeployed and thus reloaded in a different classloader ? The timer would be created again, because static refs are *per classloader*. The question is what happens to the old timers ? Are they GC'ed ? [Brian] Following up from our chat yesterday re: static initialization of TimeScheduler. My memory re cleanup *was* off. I was thinking of some stuff in java.util.Timer; doesn't really apply. As you suspected, if you have a static ref to a TimeScheduler you'll leak the time scheduler and whatever classloader loaded JGroups (i.e. if a user deployed JGroups in a sar or something). This isn't exact, but it shows the logical reference chain: ProtocolStack.class.timeScheduler --> TimeScheduler.poolThreads[0] --> Thread.contextClassLoader --> ClassLoader.loadedClasses --> ProtocolStack.class.timeScheduler That looks circular, but the system holds a ref to the live Thread in the middle and that keeps the whole thing from being gc'd. Perhaps a way to deal with this is to maintain a static WeakReference<TimeScheduler> and then access it via a static method. Any ProtocolStack holds a strong ref to the scheduler, preventing it being gc'd, but once all channels are closed no ProtocolStack == available for gc. FYI, I've attached a little main() class that experiments with something analogous to holding a static ref to a TimeScheduler. You can see that with the static strong ref in place, the thread and its TCCL don't get gc'd but once only a static WeakReference is held, things get cleaned up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira