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

globalThreadGroup not destroyed creates a classloader memory leak

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 3.0.1
    • Fix Version/s: 3.2.2, 3.3
    • Labels:
      None
    • Environment:

      linux w/ java 1.6

    • Workaround Description:
      Hide

      It is possible to manually destroy the thread group at web application shutdown (for example, in the destroy() method of a servlet):

      ThreadGroup globalThreadGroup = Util.getGlobalThreadGroup();
       
      if (!globalThreadGroup.isDestroyed()) {
       
          if (globalThreadGroup.activeCount() > 0) {
              mLog.warn("Active threads still running in JGroups global thread group.  Waiting 2 seconds.");
              try {
                  Thread.sleep(2000);
              } catch (InterruptedException exception) {
                  Thread.currentThread().interrupt();
              }
          
              if (globalThreadGroup.activeCount() > 0) {
                  mLog.warn("Active threads still running in JGroups global thread group.  Interrupting all threads.");
                  globalThreadGroup.interrupt();
              } else {
                  mLog.info("No active threads in JGroups global thread group.");
              }
          }
       
          try {
              globalThreadGroup.destroy();
          } catch (Exception exception) {
              mLog.error("Error while destroying JGroups global thread group.", exception);
          }
      }
      
      

      Show
      It is possible to manually destroy the thread group at web application shutdown (for example, in the destroy() method of a servlet): ThreadGroup globalThreadGroup = Util.getGlobalThreadGroup();   if (!globalThreadGroup.isDestroyed()) {   if (globalThreadGroup.activeCount() > 0) { mLog.warn("Active threads still running in JGroups global thread group. Waiting 2 seconds."); try { Thread.sleep(2000); } catch (InterruptedException exception) { Thread.currentThread().interrupt(); } if (globalThreadGroup.activeCount() > 0) { mLog.warn("Active threads still running in JGroups global thread group. Interrupting all threads."); globalThreadGroup.interrupt(); } else { mLog.info("No active threads in JGroups global thread group."); } }   try { globalThreadGroup.destroy(); } catch (Exception exception) { mLog.error("Error while destroying JGroups global thread group.", exception); } }

      Description

      When all channels are closed, the globalThreadGroup is not destroyed. For a normal (i.e. non-web) application, this is not a problem since the process will exit anyway. However, for a Java Enterprise web application, this causes a classloader memory leak since the ThreadGroup object has strong references to JGroups instances having strong references to their class object having strong reference to their class loader. Since the class loader is pointed by strong references, the it cannot be garbage collected and hence a leak is created each time the web application is stopped.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  belaban Bela Ban
                  Reporter:
                  gawi Jean-Philippe Gariepy
                • Votes:
                  1 Vote for this issue
                  Watchers:
                  5 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: