weblogic.common.resourcepool.ResourceDeadException

Application deployed on WLS 9.2 MP3 connects to the MQ server. At times they get the following exception in the WLS log:

2011-10-17 08:19:53,770 OFCLVGateway - Inbound Thread #2 com.dovetailsys.gateway.jms.XAJMSAdaptor -
javax.transaction.TransactionRolledbackException: EJB Exception: :
javax.ejb.EJBException: nested exception is: javax.jms.JMSException:
J2EE:160062There was an error with a resource pool used to pool JMS
sessions: weblogic.common.resourcepool.ResourceDeadException
javax.jms.JMSException: J2EE:160062 There was an error with a resource pool
used to pool JMS sessions:
weblogic.common.resourcepool.ResourceDeadException
at
weblogic.deployment.jms.JMSExceptions.getJMSException(JMSExceptions.java:29)
at
weblogic.deployment.jms.JMSSessionPool.doGetSession(JMSSessionPool.java:621)
at
weblogic.deployment.jms.JMSSessionPool.getSession(JMSSessionPool.java:409)
at
weblogic.deployment.jms.PooledConnection.doCreateSession(PooledConnection.ja
va:259)
at
weblogic.deployment.jms.WrappedConnection.createQueueSession(WrappedConnecti
on.java:134)
at
com.dovetailsys.gateway.jms.ResponseOperationsBean.receiveTextMessageFromQue
ue(ResponseOperationsBean.java:176)
at
com.dovetailsys.gateway.jms.ResponseOperationsBean.receiveTextMessageFromQue
ue(ResponseOperationsBean.java:138)
at
com.dovetailsys.gateway.jms.ResponseOperations_cc7m5m_EOImpl.receiveTextMess
ageFromQueue(ResponseOperations_cc7m5m_EOImpl.java:60)
at com.dovetailsys.gateway.jms.XAJMSAdaptor.read(XAJMSAdaptor.java:140)
at
com.dovetailsys.q5.gateway.GatewayInboundThread.adaptorRead(GatewayInboundTh
read.java:234)
at
com.dovetailsys.q5.gateway.GatewayInboundThread.process(GatewayInboundThread
.java:50)
at com.dovetailsys.q5.gateway.GatewayThread.run(GatewayThread.java:100)
Caused by: javax.ejb.EJBException: nested exception is:
javax.jms.JMSException: J2EE:160062There was an error with a resource pool
used to pool JMS sessions:
weblogic.common.resourcepool.ResourceDeadException

There is a known issue with the IBM JMS MQClient not correctly delivering events to registered ExceptionListeners for non-asynchronous connections/sessions, which can cause stale connections to accumulate in the WLS pool managed by the JMS wrapper code. One immediate work-around is to allow temporary queue creation on the target QueueManager so that the WLS JMS wrapper can send itself periodic test messages via the temporary queue in order to keep track of connection health. Otherwise, this has been fixed in MQ V6.0 Refresh Pack 6.0.2.0 (and later versions) but requires explicitly setting the Java system property where the MQClient libraries are being used (meaning, on your WLS instance that uses MQClient)

-DactivateExceptionListener=true

IBM’s Bug Extract:

Problem summary **************************************************************** USERS AFFECTED: As per JMS specifications: When an ExceptionListener is registered with a connection, then any connection broken exception should be notified to the ExceptionListener (if registered). Hence any customer implementing this feature within their application might hit upon this problem, where the connection broken exception may not get delivered to the ExceptionListener.

Platforms affected: All Distributed (iSeries, all Unix and Windows) +Java **************************************************************** PROBLEM SUMMARY: WebSphere MQ as JMS provider NOT adhering to JMS Specifications as per Section “4.3.8 ExceptionListener”. After discussing with Sun MicroSystems it was confirmed that we need to make modifications to our product to support the way ExceptionListener has to be handled.

As per JMS specifications: When an ExceptionListener is registered with a connection, then any connection broken exception should be notified to the ExceptionListener (if registered).

Currently, only in case of Asynchronous Delivery, we deliver the connection broken exceptions to the Exception Listener. In the case of a Synchronous call, even if the Exception Listener is registered the exceptions are not delivered to the ExceptionListener. Problem conclusion After this fix, any connection broken exceptions (for both Synchronous and Asynchronous) would be delivered to the ExceptionListener, if the ExceptionListener is registered.

To ensure that the existing customers are unaffected by this new change a new parameter is introduced to activate this feature. Hence any application which requires the exceptions to be delivered to the ExceptionListener must enable this parameter.

-DactivateExceptionListener=true will enable this new feature. .for example

java -DactivateExceptionListener=true MyApplication.class will activate this new feature when the MyApplication is being executed. The value ‘true’ must be passed to the parameter. A value ‘false’ or any other value or if this value is not passed as a parameter then this new changes would not be enabled.

When this parameter is enabled if any Connection Broken exceptions occurs during the program execution then that exception would be delivered to the ExceptionListener, the list of Exceptions currently identified that would be triggered when the connection breaks are as follows: MQRC_CONNECTION_BROKEN MQRC_Q_MGR_QUIESCING MQRC_Q_MGR_STOPPING MQRC_CONNECTION_ERROR MQRC_CLIENT_CONN_ERROR MQRC_CHANNEL_STOPPED_BY_USER MQRC_CONNECTION_STOPPING MQRC_CONNECTION_QUIESCING MQRC_Q_MGR_NOT_ACTIVE MQRC_HCONN_ERROR MQRC_HOBJ_ERROR MQRC_Q_MGR_NOT_AVAILABLE

Hence, with the -DactivateExceptionListener=true parameter enabled all the connection broken exceptions would be delivered to the ExceptionListener (if registered)

————————————————————— The fix is targeted for delivery in the following PTFs: