PK18536: MQ V6 PROBLEMS USING MDBS: EC3 ABEND WITH RC 04130004 DUE TO MDBTIMEOUT and POTENTIAL MDB PERFORMANCE IMPACTs

 A fix is available

Obtain the fix for this APAR



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 information
APAR number PK18536
Reported component name WEBSPHERE FOR Z
Reported component ID 5655I3500
Reported release 500
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Special Attention NoSpecatt
Submitted date 2006-01-25
Closed date 2006-02-12
Last modified date 2006-04-05

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

APAR is sysrouted TO one or more of the following:

Modules/Macros
BBOUBINF          

Publications Referenced

Fix information
Fixed component name WEBSPHERE FOR Z
Fixed component ID 5655I3500

Applicable component levels
R500 PSY UK12774    UP06/03/24 P F603

  Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.


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