PK31119: SCHEDULER THREAD PRIORITY HAS NO EFFECT FOR ALARM THREADS BUT DOES FOR ORDINARY THREADS, USING WORKMANAGER ADMIN

6.1.0.7: WebSphere Application Server V6.1 Fix Pack 7 for Solaris
6.1.0.7: WebSphere Application Server V6.1 Fix Pack 7 for HP-UX
6.1.0.7: WebSphere Application Server V6.1 Fix Pack 7 for Linux
6.1.0.7: WebSphere Application Server V6.1 Fix Pack 7 for Windows
6.1.0.7 WebSphere Application Server V6.1 Fix Pack 7 for AIX
6.1.0.7: WebSphere Application Server V6.1 Fix Pack 7 for i5/OS
Java SDK 1.5 SR8 Cumulative Fix for WebSphere Application Server
Java SDK 1.5 SR8 Cumulative Fix for WebSphere Application Server
Java SDK 1.5 SR10 Cumulative Fix for WebSphere Application Server
6.1.0.31: Java SDK 1.5 SR11 FP1 Cumulative Fix for WebSphere Application Server
6.1.0.33: Java SDK 1.5 SR12 FP1 Cumulative Fix for WebSphere
6.1.0.29: Java SDK 1.5 SR11 Cumulative Fix for WebSphere Application Server
6.1.0.35: Java SDK 1.5 SR12 FP2 Cumulative Fix for WebSphere
6.1.0.37: Java SDK 1.5 SR12 FP3 Cumulative Fix for WebSphere
6.1.0.39: Java SDK 1.5 SR12 FP4 Cumulative Fix for WebSphere Application Server
6.1.0.41: Java SDK 1.5 SR12 FP5 Cumulative Fix for WebSphere Application Server
6.1.0.43: Java SDK 1.5 SR13 Cumulative Fix for WebSphere Application Server
6.1.0.45: Java SDK 1.5 SR14 Cumulative Fix for WebSphere Application Server
6.1.0.47: WebSphere Application Server V6.1 Fix Pack 47
6.1.0.47: Java SDK 1.5 SR16 Cumulative Fix for WebSphere Application Server
6.1.0.9: WebSphere Application Server V6.1 Fix Pack 9 for Solaris

APAR status

• Closed as new function.

Error description

• - There are two types of threads, that are managed by a
  WorkManager:
     1. Ordinary threads (the threads, that are used, when
  WorkManager startWork() is called)
     2. Alarm threads
  
  - The WebSphere Scheduler uses Alarm threads.
  - The attribute 'thread-priority' in the
  WorkManager-Administration has an effect only on Ordinary
  threadsm *not* on Alarm threads.
  
  The documentation says that the priority affects *all* threads
  in the WorkManager.
  
  So how can I set the priority of tasks, that are run by the
  WebSphere-Scheduler?
  
  Customer's workaround is, that the task itself starts a new
  thread by calling startWork() but this is not very elegant.
  In his opinion, it is a very common requirement in
  batch-processing to start some long-running batches
  start some long-running batches with a lower priority than
  short-running batches or dialog-processing.
  
  Configuring work managers:
  http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?
  topic=/c
  om.ibm.websphere.nd.doc/info/ae/asyncbns/tasks/tasb_workmanager.
  html
  
  Work Managers:
  http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?
  topic=/c
  om.ibm.websphere.nd.doc/info/ae/asyncbns/concepts/casb_workmgr.h
  tml
  
  Sun:
  http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Thread.html
  
  So from the documentation links referenced, it looks like
  possibly could use setPriority for Alarm threads by extending
  java.lang.Thread for public class Alarm.
  

Local fix

• N/A
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: Websphere Application server version 6 users *
  *                 who use async bean alarm managers            *
  ****************************************************************
  * PROBLEM DESCRIPTION: Thread priority value was being         *
  *                      ignored for alarm manager threads       *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The async bean code was not setting the thread priority for
  alarm manager threads even if the value was set.
  

Problem conclusion

• Added thread priorty value to all alarm manager threads so
  this value will now be set and honored on async bean alarm
  manager threads.
  
  The fix for this APAR is currently targeted for inclusion
  in fixpacks 6.0.2.17 and 6.1.0.7.
  Please refer to the recommended updates page for delivery
  information:
  http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
  

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:

Modules/Macros

• SCHEDULR
  

Fix information

• Fixed component name

  WEBS APP SERV N

• Fixed component ID

  5724H8800

Applicable component levels

• R60A PSY

     UP

• R60H PSY

     UP

• R60I PSY

     UP

• R60P PSY

     UP

• R60S PSY

     UP

• R60W PSY

     UP

• R60Z PSY

     UP

• R61A PSY

     UP

• R61H PSY

     UP

• R61I PSY

     UP

• R61P PSY

     UP

• R61S PSY

     UP

• R61W PSY

     UP

• R61Z PSY

     UP