]
Bela Ban closed JGRP-789.
-------------------------
Resolution: Won't Fix
Not needed anymore. If that's not the case, please re-open
Can't manage classloader for threads created by
TP.ProtocolAdapter
------------------------------------------------------------------
Key: JGRP-789
URL:
https://jira.jboss.org/jira/browse/JGRP-789
Project: JGroups
Issue Type: Bug
Reporter: Brian Stansberry
Assignee: Bela Ban
Fix For: 2.x
TP.ProtocolAdapter is creating a ThreadFactory, but the JGRP-764 solution of adding a
classloader management decorator to that ThreadFactory can't be applied. Problem is
the thread factory decoration is done following channel creation but before connect(), but
TP.ProtocolAdapter isn't even created until the connect phase. It's created in
Configurator.startProtocolStack().
Once this TP.ProtocolAdapter thread factory exists, all protocols higher in the stack
will use it. I find this leads to a classloader leak to the GMS$ViewHandler.thread during
channel disconnect (see JBAS-5414).
I believe the correct solution to this is to create the TP.ProtocolAdapter in
Configurator.connectProtocols(). The TP.ProtocolAdapter constructor takes cluster_name and
address params though, and those aren't known until Channel.connect(). They aren't
needed until then, either though. :) The address could be provided during the connect
phase as part of Configurator.startProtocolStack(), the way it's provided to
above_prot now. The cluster_name will presumably come down with the CONNECT event.
Besides fixing this problem, I think adding the TP.ProtocolAdapter during channel
creation is conceptually cleaner. It's really another protocol in the stack, so
having it have a lifecycle similar to the others seems good.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: