[jboss-jira] [JBoss JIRA] Updated: (JGRP-789) Can't manage classloader for threads created by TP.ProtocolAdapter

[Bela Ban (JIRA)]

     [ https://jira.jboss.org/jira/browse/JGRP-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-789:
--------------------------

    Fix Version/s: 2.x
                       (was: 2.7)
                       (was: 2.6.4)


Moved to 2.x. We'll probably never fix this one... :-)

> 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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira