[ https://issues.jboss.org/browse/JGRP-1410?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1410: --------------------------- Fix Version/s: 3.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1410?page=com.atlassian.jira.plugin.... ] Sei Syvalta commented on JGRP-1410: ----------------------------------- When org.jgroups.util.GLOBAL_GROUP is created, constructor which uses default parent is used. The parent adds reference to this new ThreadGroup GLOBAL_GROUP. From this anonymous ThreadGroup there's reference to the ClassLoader which jgroups is loaded by. In this case it is the web application class loader which means the class loader is strongly reachable and cannot be collected. Dump from jhat: --> java.lang.ThreadGroup@0x9891ff8 (43 bytes) (field groups:) --> [Ljava.lang.ThreadGroup;@0x9b86648 (24 bytes) (Element 2 of [Ljava.lang.ThreadGroup;@0x9b86648:) --> org.jgroups.util.Util$1@0xd3560e8 (43 bytes) (??:) --> class org.jgroups.util.Util$1 (84 bytes) (??:) --> weblogic.utils.classloaders.ChangeAwareClassLoader@0xbe8cca0 (89 bytes) Calling destroy() for the ThreadGroup should fix the issue, as proposed by the original reporter (it removes the reference from parent). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1410?page=com.atlassian.jira.plugin.... ] Sei Syvalta commented on JGRP-1410: ----------------------------------- JGroups creates that ThreadGroup so it would be good if JGroups would destroy (and thus unregister it from the parent) at the time of shutdown. I guess it's not so straighforward to do that. Some alternatives that come to my mind: - have distinct ThreadGroup per JChannel and destroy the ThreadGroup when the JChannel is shut down. - keep count of JChannel instances and at channel shutdown check if the channel to be shut down is the last one and destroy the ThreadGroup if it is. ThreadGroup creation would also need to be changed. This would also require some synchronization. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1410?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1410. ---------------------------- Resolution: Done OK, I moved the global thread group into the channel; it is now allocated *per channel* and destroyed in JChannel.destroy(). Let me know if this works. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1410?page=com.atlassian.jira.plugin.... ] Bela Ban reopened JGRP-1410: ---------------------------- Oh shoot. I can see that I actually did destroy the 2 thread groups in TP.destroy(), but then commented the 2 deletions, but I forgtot why... I'll look into it. Any suggestions ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1410?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1410: -------------------------------- Hmm, having the channel and pool thread groups in TP is possibly sub-optimal, as the transport can be shared by multiple JChannels. Hmm, maybe moving the channel thread group into JChannel and implementing ref counting for the pool thread groups would be the solution... Or implement ref-counting for both thread groups in the transport... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1410?page=com.atlassian.jira.plugin.... ] Vyacheslav Mishcheryakov edited comment on JGRP-1410 at 11/3/12 3:52 AM: ------------------------------------------------------------------------- I'm not familiar with java threds very well and use ehcache-jgroupsrelication (not jgroups directly) so can't suggest best solution. But when tryied appply proposed workaround to jgroups 2.10 I figured that calling globalThreadGroup.interrupt(); actually doesn't kill threads. There was 30 active threads that I was not able to finish by interrupt() method and so I couldn't destroy the thread group. was (Author: lamao): I'm not familiar with java threds very well so can't suggest best solution. But when tryied appply proposed workaround to jgroups 2.10 I figured that calling globalThreadGroup.interrupt(); actually doesn't kill threads. There was 30 active threads that I was not able to finish by interrupt() method and so I couldn't destroy the thread group. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1410?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1410. ---------------------------- Resolution: Done I removed the use of ThreadGroup, as suggested in my prev comment. I also fixed a bug that caused timer threads to have a null or <ADDR> cluster name when a shared transport was used. Let me know if this fixes your classloading leak, and re-open if the leak still exists. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira