This content has been marked as final. Show 7 replies
by looking @
reason codes: Resource weblogic.deployment.jms.WrappedXAResource_com_ibm_mq_jmqi_JmqiXAResource declared unhealthy
it seems that your JMS Adapter is available or inactive mode while doing transaction.
Try to untraget and trarget it again it should work.
Please raise a ticket with Oracle support ticket also that will help you to get more near to root cause....
I googled The method 'xa_end' has failed with errorCode '100'., which yielded this from IBM:
http://www-01.ibm.com/support/docview.wss?uid=swg21508472I realize this advice is meant to apply to WAS, but perhaps MQ is running the same type of connection pool implicitly on WL.
The cause of these errors is usually the result of a WebSphere MQ messaging provider JMS Connection being closed off by WebSphere Application Server because the Aged timeout for the Connection has expired.
To resolve this issue, ensure that the JMS Connection Factory being used by the application has the Connection Pool property Aged timeout set to zero. This will prevent JMS Connections being closed when they are returned to the Free Pool, and so ensures that any outstanding transactional work can be completed.
Thanks for looking into this Tom.
I did check with IBM support if there is any "Aged Time Out" setting on the connection factory or on the MQ end that I could change but they mentioned it is the setting that need to be made on the Weblogic end. Do you know anything about this setting on weblogic server?
There is no way for WebLogic to configure specific proprietary attributes such as "Aged Time Out" on a foreign vendor's connection factory as this is not covered by the JMS or Java EE specifications. WebLogic simply uses an existing IBM connection factory that it has been told to find by looking it up in the foreign provider's JNDI.
In other words, a WebLogic administrator/developer only configures the URL of the foreign provider's JNDI implementation and the CF name for the JNDI location of a foreign provider's CF. Typically this configuration is accomplished using WebLogic's Foreign JMS Server feature, which essentially maps remote JNDI entries into local JNDI. The foreign JNDI and CF are themselves configured by the foreign provider's tooling.
Is the MQ queue being used in this transaction a local queue on the same queue manager where client connects or some kind or clustered queue or remote queue for which the consumer may be on a different queue manager?
I don't have a solution here but we have a similar problem where we may receive messages on different servers and may route it to a single consumer on some other box reading on a queue. each box has its own queue manager so the consumer's queue is clustered for all producers to put messages on it.