[
http://jira.jboss.com/jira/browse/JGRP-737?page=comments#action_12410243 ]
Brian Stansberry commented on JGRP-737:
---------------------------------------
Neglected to mention that there are other calls to getProtocolStack().getThreadFactory()
scattered about. I didn't think those were a big deal, since the stack's thread
factory doesn't get "stopped" at channel disconnect. I see now that the
TCP.getConnectionTable call I mentioned in the description is one of those; maybe not as
big a deal.
Shared transport protocols use stack field from first channel
created
---------------------------------------------------------------------
Key: JGRP-737
URL:
http://jira.jboss.com/jira/browse/JGRP-737
Project: JGroups
Issue Type: Bug
Affects Versions: 2.6.2
Reporter: Brian Stansberry
Assigned To: Bela Ban
Priority: Critical
Fix For: 2.6.3, 2.7
For example, TP.timer is set to TP.stack.timer. TP.stack belongs to an individual
channel, not to the set of channels associated with a shared transport.
Disconnect the first channel and the others go boom.
Did a quick scan of usage of the 'stack' field or the
'getProtocolStack()' method in TP and its subclasses. This usage for the timer is
one. Others are:
1) TCP.getConnectionTable calls
cTable.setThreadFactory(getProtocolStack().getThreadFactory());
2) handleDiagnosticProbe uses stack.getChannel()
--
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