PQ60787: CREATION/DESTRUCTION OF ALARM THREADS RESULTS IN INCREASING THREAD IDS, AND MAY ULTIMATELY RESULT IN JVMCRASH/HANG | |||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description WebSphere Application Server 4.0.2 is experiencing a problem with excessively high thread ID for the Alarm Thread. There can be a problem with the Alarm thread management. In 4.02 the alarm thread pool size is set to 1, and if morethan one alarm fires concurrently, new threads are created to handle the alarm. At the end of handling the alarm, only one alarm is retur ned to the pool, while the remaining threads are destroyed. Alarms are used by WAS to check whether reloadable war files hav ave been updated. For some applications, such as WPS,there can be up to 90 alarms created, of which, at any given time10 can fire. over time, this creation/destruction of alarm threads may ultimately result in JVM hang/crash Defects 121091 and 121279Local fix Problem summary **************************************************************** * USERS AFFECTED: WebSphere Application Server users who * * constantly update the war files. * **************************************************************** * PROBLEM DESCRIPTION: Problem with the Alarm thread * * management. * **************************************************************** * RECOMMENDATION: * **************************************************************** Problem with the Alarm thread management - In 4.02 the alarm thread pool size is set to 1, and if more than one alarm fires concurrently, new threads are created to handle the alarm. At the end of handling the alarm, only one alarm is returned to the pool, while the remaining threads are destroyed. Alarms are used by WAS to check whether reloadable war files have been updated. For some applications, such as WPS, there can be up to 90 alarms created, of which, at any given time 10 can fire. Over time, this creation/destruction of alarm threads may ultimately result in JVM hang/crash.Problem conclusion This defect is being opened with regard to Alarm Thread not reusing threads thus causing each time one is spawned a thread to be generated dynamically. This is fixed by making Alarm use ThreadPooling.Temporary fix \\wasdoc0\ \\wasdoc0\apars\PQ60787\v4.0.2Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
SRLS
|
Document Information |
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ60787
IBM Group: Software Group
Modified date: May 15, 2003
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.