PH55283: CLASS LOADER LEAK IN WORK MANAGER DAEMON THREAD

APAR status

• Closed as program error.

Error description

• WorkManagerDaemonThread has one field, which is a Runnable,
  public class WorkManagerDaemonThread extends Thread
         final Runnable workItem;
  
  The WorkManagerDaemonThread is running a SchedulerDaemonImpl,
  
  java.lang.ThreadGroup[name=WebSphere_EJB_Timer_Service_WorkMana
  ger:WAS Scheduler: WebSphere_EJB_Timer_Service,maxpri=10]
   at java.lang.Object.wait(JI)V (Native Method)
   at java.lang.Object.wait(J)V (Object.java:216(Compiled Code))
   at com.ibm.ws.scheduler.SchedulerDaemonImpl.run()V
  (SchedulerDaemonImpl.java:548)
   at com.ibm.ws.asynchbeans.J2EEContext$RunProxy.run()Ljava/lang
  /Object;(J2EEContext.java:281)
   ...
  
  DaemonCoordinatorImpl.startDaemons creates SchedulerDaemonImpl,
   which invokes SchedulerDaemonImpl to submit itself to the
  Asynchbeans WorkManager:
                 wm.startWork(this, true);
  
  The Runnable in this case is an AsynchBeans WorkItemImpl, which
  has
  	protected J2EEContext creatorContext;
  which contains context captured from the submitting thread,
  including the class loader.
  
  When DaemonCoordinatorImpl.startDaemons is invoked by
  SchedulerServiceImpl.autoStartDaemon(com.ibm.ws.scheduler.spi.S
  chedulersched)
  this should be fine because there would not be an application
  class loader on the thread.
  
  However, DaemonCoordinatorImpl.startDaemons can also be invoked
  by SchedulerImpl.startDaemon(final Integer delay), where an
  application class loader could be on the thread.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:  All users of IBM WebSphere Application      *
  *                  Server using Scheduler.                     *
  ****************************************************************
  * PROBLEM DESCRIPTION: A scheduler memory leak can occur if    *
  *                      the application class loader is used    *
  *                      while starting the daemons.             *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  WorkManagerDaemonThread has one field, which is a Runnable,
  public class WorkManagerDaemonThread extends Thread
  final Runnable workItem;
  The WorkManagerDaemonThread is running a SchedulerDaemonImpl,
  java.lang.ThreadGroup[name=WebSphere_EJB_Timer_Service_WorkMana
  ger:WAS Scheduler: WebSphere_EJB_Timer_Service,maxpri=10]
  at java.lang.Object.wait(JI)V (Native Method)
  at java.lang.Object.wait(J)V (Object.java:216(Compiled Code))
  at com.ibm.ws.scheduler.SchedulerDaemonImpl.run()V
  (SchedulerDaemonImpl.java:548)
  at com.ibm.ws.asynchbeans.J2EEContext$RunProxy.run()Ljava/lang
  /Object;(J2EEContext.java:281)
  ...
  DaemonCoordinatorImpl.startDaemons creates SchedulerDaemonImpl,
  which invokes SchedulerDaemonImpl to submit itself to the
  Asynchbeans WorkManager:
  wm.startWork(this, true);
  The Runnable in this case is an AsynchBeans WorkItemImpl, which
  has
  protected J2EEContext creatorContext;
  which contains context captured from the submitting thread,
  including the class loader.
  When DaemonCoordinatorImpl.startDaemons is invoked by
  SchedulerServiceImpl.autoStartDaemon(com.ibm.ws.scheduler.spi.S
  chedulersched)
  this should be fine because there would not be an application
  class loader on the thread.
  However, DaemonCoordinatorImpl.startDaemons can also be invoked
  by SchedulerImpl.startDaemon(final Integer delay), where an
  application class loader could be on the thread.
  

Problem conclusion

• The application class loader is temporarily removed when
  starting the daemons.
  
  The fix for this APAR is targeted for inclusion in fix pack
  8.5.5.25 and 9.0.5.18. For more information, see 'Recommended
  Updates for WebSphere Application Server':
  https://www.ibm.com/support/pages/node/715553
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  WEBS APP SERV N

• Fixed component ID

  5724H8800

Applicable component levels