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

[Brian Stansberry (JIRA)]

    [ http://jira.jboss.com/jira/browse/JGRP-789?page=comments#action_12418214 ] 
            
Brian Stansberry commented on JGRP-789:
---------------------------------------

I can provide a patch implementing the above for Branch_2_6 if desired.  It's not a proper patch; i.e. I ran the testsuite and got failures. Could be completely unrelated; some seem unrelated, and I haven't run the JGroups testsuite in a long time so have no baseline. So, a "draft" of a patch to perhaps save some time.

I semi-volunteer to handle this myself; have to see what schedule look like when the time comes that you want it handled. :)

> Can't manage classloader for threads created by TP.ProtocolAdapter
> ------------------------------------------------------------------
>
>                 Key: JGRP-789
>                 URL: http://jira.jboss.com/jira/browse/JGRP-789
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Brian Stansberry
>         Assigned To: Bela Ban
>
> 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: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira