PQ70933: CANCELLING AN ASYNCHBEAN ALARM MAY CAUSE A DEADLOCK. | |||||||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description When using Asynchronous Beans alarms on a multi-processor machine it may be possible that cancelling an alarm may cause a deadlock if there is a lot of alarms running at the same time. This scenario can be confirmed by dumping the JVM threads and checking to see if the following object monitor locks are deadlocked: com.ibm.ws.asynchbeans.am._AlarmLocal fix Problem summary **************************************************************** * USERS AFFECTED: All WebSphere Application Server Enterprise * * 5.0 developers using Asynchronous Beans or * * Scheduler. * **************************************************************** * PROBLEM DESCRIPTION: When using Asynchronous Beans alarms * * on a multi-processor machine it may * * be possible that cancelling an alarm * * may cause a deadlock if there is a * * lot of alarms running at the same * * time. * **************************************************************** * RECOMMENDATION: Apply available fixpack. * **************************************************************** Two objects are being synchronized in such a way that could cause a deadlock when an alarm is cancelled.Problem conclusion The two objects being synchronized have been refactored into a single object to remove the deadlock scenario.Temporary fix Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
Publications Referenced
|
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server > Enterprise Edition (EE)
Operating system(s):
Software version: 00W
Software edition:
Reference #: PQ70933
IBM Group: Software Group
Modified date: Mar 10, 2003
(C) Copyright IBM Corporation 2000, 2008. All Rights Reserved.