PK18536: MQ V6 PROBLEMS USING MDBS: EC3 ABEND WITH RC 04130004 DUE TO MDBTIMEOUT and POTENTIAL MDB PERFORMANCE IMPACTs | |||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description MDBs in WebSphere for z/OS can listen for new messages in a listener Port from the Servant or the Control region. . Aside from one exception, the correct behavior for all MDBs is to listen for new messages from the Control region. The only exception to this are MDBs listening on a Topic with a non-durable subscription. . When using MQ V6 with WebSphere, without this APAR being applied, all MDBs will listen for messages in the Servant Region. . MDBs listening in the Servant region can cause a few implications which are documented below. This APAR corrects the behavior in WebSphere for z/OS, so that all MDBs listen from the Control region when using MQ V6. Once again, the only exception to this are MDBs listening on a Topic with a non-durable subscription. . Implications of listening in the Servant region: **************************************************************** * 1. MDBs constrained by control_region_wlm_dispatch_timeout * **************************************************************** Usually the length of time an MDB request is allowed to execute, is constrained by the following timeout variable: control_region_mdb_request_timeout. . However, when MDBs are listening-in-Servant, they are contrained by the time specified in: control_region_wlm_dispatch_timeout. . Therefore, when using WebSphere for z/OS with MQ V6, before this APAR is applied, WebSphere may encounter EC3 timeout ABENDs with RC=04130004; which indicates a WLM Dispatch timeout. This is due to MDB requests not completing within the time specified by control_region_wlm_dispatch_timeout. . Here is a sample stack trace we observed for the failing TCB: . <MDB Application Code> com/ibm/ejs/jms/listener/MDBWrapper$PriviledgedOnMessage.run com/ibm/ws/security/util/AccessController.doPrivileged com/ibm/ejs/jms/listener/MDBWrapper.callOnMessage com/ibm/ejs/jms/listener/MDBWrapper.onMessage com/ibm/mq/jms/MQSession.run com/ibm/ejs/jms/JMSSessionHandle.run com/ibm/ejs/jms/listener/ServerSession.connectionConsumerOnMessa ge com/ibm/ejs/jms/listener/ServerSession.onMessage com/ibm/ejs/jms/listener/WS390ServerSession.onMessage com/ibm/ejs/jms/listener/ServerSession.dispatch sun/reflect/GeneratedMethodAccessor37.invoke sun/reflect/DelegatingMethodAccessorImpl.invoke java/lang/reflect/Method.invoke com/ibm/ejs/jms/listener/ServerSessionDispatcher.dispatch com/ibm/ejs/container/MDBWrapper.onMessage com/ibm/ejs/container/MDBWrapper.onMessage com/ibm/ejs/jms/listener/ServerSession.run com/ibm/ejs/jms/listener/MDBCppUtilitiesInterfaceImpl.onMessage com/ibm/ws390/mdb/MDBCppUtilities.onMessage . The above MDB timed out even though MDB timeouts were DISABLED, i.e. the control_region_mdb_request_timeout was set to 0. . The timeout constraints were being imposed by the control_region_wlm_dispatch_timeout variable, which is unexpected. Usually, we would expect control_region_mdb_request_timeout to be in effect. . As mentioned before, the control_region_wlm_dispatch_timeout is being imposed because of an interoperibility issue with WebSphere and MQ V6 which causes all MDBs to listen for messages in the Servant region, instead of listening in the Control region. . This APAR will resolve the interoperability issue so that MDBs by default will always listen in the Control region. This in-turn will correct WebSphere's behavior regarding MDB timeouts, so that MDB requests are only constrained by the variable : control_region_mdb_request_timeout. . **************************************************************** * 2. Potential Performance Impact assocated with MDBs * **************************************************************** Some performance impact may be observed when using MDBs with MQ V6 and WebSphere. Without this APAR Applied, when using MQ V6, all MDBs will listen for new messages from the Servant region, which may cause some performance overheads. Once this APAR is applied, MDBs will resume listening in the Control region, and therefore we expect any Performance impacts caused by listening in the Servant Region to be removed. LOCAL FIX: The local fix to prevent MDB timeouts is to increase the control_region_wlm_dispatch_timeout so that MDB requests can complete within the specified time. . Please note that disabling this timeout variable can cause further problems with regards to running out of available WebSphere Managed Threads for application processing. . This apar provides fix for control_region_mdb_request_timeout. Symptoms may also include problems with WLM classification file for the MDB's. The WLM issues showed up after upgrading to MQ V6. Customer could not see CPU usage for the MDB's, could not gather SMF records containing 'response time information for specific transactions.' These were working fine before upgrading to MQ V6.Local fix The local fix is to increase the control_region_wlm_dispatch_timeout so that MDB requests can complete within the specified time. . Please note that disabling this timeout variable can cause further problems with regards to running out of available WebSphere Managed Threads for application processing.Problem summary **************************************************************** * USERS AFFECTED: All users of WebSphere Application Server * * V5.0 for z/OS * **************************************************************** * PROBLEM DESCRIPTION: WebSphere Application Server for z/OS * * ABENDs with EC3, RC 04130004, * * WLM queue timeout. The problem occurs * * when WebSphere MQ Version 6 resources * * are used by the Message-Driven Bean * * (MDB) Listener Port. * * * * WebSphere Application Server * * (MDB) support should be listening in * * the controller instead it is * * incorrectly listening in the servants. * **************************************************************** * RECOMMENDATION: * **************************************************************** One or more of the following symptoms may be observed for the problem of incorrectly listening in the servants for MDB Listener Ports when using WebSphere MQ Version 6: The Listener Port "Maximum messages" setting is incorrectly processed which may cause multiple messages to be dispatched in a single transaction. The "Maximum messages" setting is internally set to '1' when listening in the controller. But "Maximum messages" may have been set externally to a value greater then '1'. Because we are mistakenly listening in the servants the external "Maximum messages" setting is used which causes the multiple messages. Since a "Maximum messages" value greater than '1' results in multiple messages dispatched in a single transaction (assuming the queue or topic is sufficiently loaded), you can end up with an unintended transaction scope. This can result in extra processing in cases in which one message forces a rollback (since all will roll back). It also may cause you to hit the transaction timeout when this would not have come into play had you been dispatching one message per tran. Another side effect would be the fact that your application dispatch is subject to the timeout set by 'control_region_wlm_dispatch_timeout' variable rather than the timeout set by the 'control_region_mdb_request_timeout' variable. Finally, performance may be degraded because of the incorrect processing.Problem conclusion The code has been fixed to correctly listen in the controller when using WebSphere MQ Version 6 resources. APAR PK18536 is currently targeted for inclusion in SERVICE LEVEL W502039 of WebSphere Application Server V5.0 for z/OS.Temporary fix Comments
APAR is sysrouted FROM one or more of the following: PK17823 APAR is sysrouted TO one or more of the following: Modules/Macros
Publications Referenced
|
Document Information |
Current web document: swg1PK18536.html
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server for z/OS
Operating system(s):
Software version: 500
Software edition:
Reference #: PK18536
IBM Group: Software Group
Modified date: Apr 5, 2006
(C) Copyright IBM Corporation 2000, 2009. All Rights Reserved.