Bug 536605 (RHQ-938)

Summary: remove XA from JMS data source configuration
Product: [Other] RHQ Project Reporter: John Mazzitelli <mazz>
Component: Core ServerAssignee: RHQ Project Maintainer <rhq-maint>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: urgent    
Version: 1.1Keywords: Improvement
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
URL: http://jira.rhq-project.org/browse/RHQ-938
Whiteboard:
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: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 534381    

Description John Mazzitelli 2008-10-03 17:29:00 UTC
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 13:04:19 UTC
some of the configuration is also gonna be touched by RHQ-895

Comment 2 John Mazzitelli 2008-11-03 20:59:08 UTC
this is a blocker - we need to fix the transactioning issues

Comment 3 John Mazzitelli 2008-11-22 21:32:09 UTC
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 22:28:22 UTC
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 05:13:18 UTC
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-24 00:52:58 UTC
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 20:21:29 UTC
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 20:26:26 UTC
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 21:20:00 UTC
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