[ http://jira.jboss.com/jira/browse/JGRP-541?page=all ] Bela Ban updated JGRP-541: -------------------------- Fix Version/s: 2.5 -- 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

[ http://jira.jboss.com/jira/browse/JGRP-541?page=comments#action_12367289 ] Bela Ban commented on JGRP-541: ------------------------------- I agree with Vladimir's assertion. The channel needs to be closed correctly for these threads to terminate. -- 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

[ https://issues.jboss.org/browse/JGRP-541?page=com.atlassian.jira.plugin.s... ] Peter Novak commented on JGRP-541: ---------------------------------- In our environment we have similar problem like https://issues.jboss.org/browse/ISPN-1444. It is testing environment where we execute some testing scripts that are using Infinispan as a Cache provider. For this environment we have special configuration, where Infinispan Threads are created as DAEMON threads, because we need to stop the JVM instance, when the executed scripts finished. We don´t want to put the System.exit(0) into scripts, because it avoids the re-usability. We already have configured the Infinispan to support non-daemon threads for this environment, but it does not stop, because it is using the JGroups and there is no possibility to configure the ThreadPools to create Daemons threads for this situation. I understand your motivation for "non daemon threads", and I agree, that by default it should be "non daemon", but In my opinion, there are some situations, where this config parameter could be very helpful. We use the jgroups-2.12.1.3.Final. Please, add some configuration parameter to provide choice for your users, like it is in Infinispan. Thank you. -- 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-541?page=com.atlassian.jira.plugin.s... ] Peter Novak commented on JGRP-541: ---------------------------------- We use Spring and the scripts and components use the Spring Cache Abstraction. So they don´t need to know what cache implementation is used for execution. The scripts/test does not manage the caches, they only PUT/GET values, so they don´t call Jgroups, they could not call stop(), close() or other kind of shutdown on the cache. Yes, I know, I can use the setThreadFactory invocation to manipulate this settings from code, but this requires to find the right place, where to call this - may be some patching of Infinispan Code, where the JGroups is initialized, before it is used. I´m not sure, how to do it right way. But everything, what I need to do, is to have 2 or more configuration profiles for Spring - one for production, one for testing, etc. And in testing profile use the JGroups XML config with ThreadPoolFactoryClass=MyThreadPoolFactory or ThreadPool.threadType=daemon. May be, it is not the JGroups issue, but Infinispan Issue, that when I setup the DAEMON_THREADS support for Infinispan, than Infinispan should call the TP.setThreadFactory(ThreadFactory new_factory) and use the proper factory, but by https://issues.jboss.org/browse/ISPN-1444 it is not Infinispan problem, but JGroups problem - and I´m in cycle :). The workaround for us now is to replace the Infinispan Cache implementation with some other (like EHCache) configuration for testing profile. May be later we will find some better way, how to shutdown the Cache with JGroups correctly. -- 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