Bug 536605 - (RHQ-938) remove XA from JMS data source configuration
remove XA from JMS data source configuration
Status: CLOSED NOTABUG
Product: RHQ Project
Classification: Other
Component: Core Server (Show other bugs)
1.1
All All
urgent Severity medium (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
http://jira.rhq-project.org/browse/RH...
: Improvement
Depends On:
Blocks: RHQ-1183
  Show dependency treegraph
 
Reported: 2008-10-03 13:29 EDT by John Mazzitelli
Modified: 2009-11-10 16:22 EST (History)
0 users

See Also:
Fixed In Version: 1.2
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Mazzitelli 2008-10-03 13:29:00 EDT
Currently, our JMS data source is configured with XA transactioning.  See the jms-ds (both oracle and postgres) configuration files.

  <!-- The JMS provider loader -->
  <mbean code="org.jboss.jms.jndi.JMSProviderLoader"
	 name="jboss.mq:service=JMSProviderLoader,name=JMSProvider">
    <attribute name="ProviderName">DefaultJMSProvider</attribute>
    <attribute name="ProviderAdapterClass">
      org.jboss.jms.jndi.JNDIProviderAdapter
    </attribute>
    <!-- The combined connection factory -->
    <attribute name="FactoryRef">java:/XAConnectionFactory</attribute>
    <!-- The queue connection factory -->
    <attribute name="QueueFactoryRef">java:/XAConnectionFactory</attribute>
    <!-- The topic factory -->
    <attribute name="TopicFactoryRef">java:/XAConnectionFactory</attribute>
    <!-- Uncomment to use HAJNDI to access JMS
    <attribute name="Properties">
       java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
       java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
       java.naming.provider.url=localhost:1100
    </attribute>
    -->
  </mbean>

...
  <!-- JMS XA Resource adapter, use this to get transacted JMS in beans -->
  <tx-connection-factory>
    <jndi-name>JmsXA</jndi-name>
    <xa-transaction/>
    <rar-name>jms-ra.rar</rar-name>
    <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
    <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>
    <max-pool-size>20</max-pool-size>
    <security-domain-and-application>JmsXARealm</security-domain-and-application>
  </tx-connection-factory>

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.
Comment 1 John Mazzitelli 2008-10-07 09:04:19 EDT
some of the configuration is also gonna be touched by RHQ-895
Comment 2 John Mazzitelli 2008-11-03 15:59:08 EST
this is a blocker - we need to fix the transactioning issues
Comment 3 John Mazzitelli 2008-11-22 16:32:09 EST
this may be relevent:

http://www.jboss.org/community/docs/DOC-11443

"Enlisting multiple 1-phase aware participants in the same transaction"
Comment 4 John Mazzitelli 2008-11-22 17:28:22 EST
http://anonsvn.labs.jboss.com/labs/jbosstm/trunk/atsintegration/docs/IntegrationGuide.odt

"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."
Comment 5 John Mazzitelli 2008-11-23 00:13:18 EST
the cause of this may or may not be related to RHQ-1170, but I am linking that jira issue here just in case.
Comment 6 John Mazzitelli 2008-11-23 19:52:58 EST
just a link  to JBM page that shows how they configure their own recovery module for JMS:

http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.3/doc/messaging/JBoss_Messaging_User_Guide/html/recovery.html
Comment 8 John Mazzitelli 2008-11-25 15:21:29 EST
we need to fix our XA recovery via the tips found here:

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=146138
Comment 9 John Mazzitelli 2008-11-25 15:26:26 EST
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
Comment 10 Red Hat Bugzilla 2009-11-10 16:20:00 EST
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

Note You need to log in before you can comment on or make changes to this bug.