Uploaded image for project: 'JGroups'
  1. JGroups
  2. JGRP-789

Can't manage classloader for threads created by TP.ProtocolAdapter

    XMLWordPrintable

Details

    • Bug
    • Resolution: Won't Do
    • Major
    • 3.5
    • None
    • None

    Description

      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.

      Attachments

        Issue Links

          Activity

            People

              rhn-engineering-bban Bela Ban
              bstansbe@redhat.com Brian Stansberry
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: