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

globalThreadGroup not destroyed creates a classloader memory leak

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 3.2.2, 3.3
    • 3.0.1
    • None
    • Workaround Exists
    • 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); } }

      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.

              rhn-engineering-bban Bela Ban
              gawi_jira Jean-Philippe Gariepy (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: