Red Hat Bugzilla – Bug 536605
remove XA from JMS data source configuration
Last modified: 2009-11-10 16:22:27 EST
Currently, our JMS data source is configured with XA transactioning. See the jms-ds (both oracle and postgres) configuration files.
<!-- The JMS provider loader -->
<!-- The combined connection factory -->
<!-- The queue connection factory -->
<!-- The topic factory -->
<!-- Uncomment to use HAJNDI to access JMS
<!-- JMS XA Resource adapter, use this to get transacted JMS in beans -->
<config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
<config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/DefaultJMSProvider</config-property>
Do a search for JmsXA to find other places where XA is configured. We should look to see if we can avoid configuring for XA since we don't have true ability to recover from 2PC txns anyway and, when errors do occur, arjuna attempts to retry the failed transactions but never can succeed.
some of the configuration is also gonna be touched by RHQ-895
this is a blocker - we need to fix the transactioning issues
this may be relevent:
"Enlisting multiple 1-phase aware participants in the same transaction"
"Further, even when the transaction is recorded ,that record may not contain all the required information. This is particularly the case when using drivers that have non-serializable XAResource implementations, which unfortunately is most of them.
To address these situations, JBossTS uses configurable recovery modules. By providing a suitable plugin for any resource manager that is used, it can be ensured that all transactions will be recovered successfully. Without such configuration, the system will keep retrying failed transactions repeatedly without success. This leads to three consequences: resource managers may remain locked, denying service to other applications until such time as an administrator intervenes; entries for the failed transactions may remain in the ObjectStore indefinitely; the recovery manager will log failed recovery attempts on each pass, leading to larger than necessary log files. These situations commonly manifest themselves by repeated log entries of the form "Could not find new XAResource to use for recovering non-serializable XAResource < id string >" Such errors can be ignored in development environments and eliminated by shutting down JBossTS and removing the contents of the ObjectStore before restarting. However, it is important to realize such log entries are indicative of misconfiguration and should be a serious concern in a production environment."
the cause of this may or may not be related to RHQ-1170, but I am linking that jira issue here just in case.
just a link to JBM page that shows how they configure their own recovery module for JMS:
and here's their recovery modules:
we need to fix our XA recovery via the tips found here:
we are not going to remove XA from the JMS config (I'm not even sure if we can).
Gonna configure the transaction manger to perform recovery properly
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-938
This bug is related to RHQ-895
This bug is related to RHQ-1017
This bug is related to RHQ-1170
This bug relates to RHQ-1032