[
http://jira.jboss.com/jira/browse/JGRP-755?page=comments#action_12412851 ]
Bela Ban commented on JGRP-755:
-------------------------------
Thinking a bit more about this, I realized that a stopping channel removes all of its
submitted tasks from the timer, so if we have 3 channels which hold refs to a singleton
timer, and they are closed, the timer has no references to any threads anymore, so it
should get GC'ed.
Oh, shit, not true: the TimeScheduler is a subclass of ScheduledThreadPoolExecutor, which
maintains a pool of threads. Unless they are daemon threads, this will prevent the timer
from being GC'ed. Do you agree on this ?
I can make the timer's threads daemon threads, which would allow timer to be
GC'ed.
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