How do I configure HornetQ to NOT use XA

[hilmer]

Hi

I wish to configure HornetQ to not use XA transactions.

I tried to change the HornetQ configuration to contain

    <transaction mode="local"/>

But when many messages arrive I still get WARNings like this:

2015-04-21 12:00:57,780 WARN  [Periodic Recovery] (arjunacore.XARecoveryModule:791):

ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_NOTA: javax.transaction.xa.XAException

        at org.hornetq.core.client.impl.ClientSessionImpl.rollback(ClientSessionImpl.java:1821)

        at org.hornetq.core.client.impl.DelegatingSession.rollback(DelegatingSession.java:514)

        at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.rollback(HornetQXAResourceWrapper.java:125)

        at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.handleOrphan(XARecoveryModule.java:786)

        at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:692)

        at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431)

        at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212)

        at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789)

        at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371)

Indicating that I'm still using XA, stuff, which is too slow to keep up.

So how du I disable XA entirely for HornetQ?

I'm running Wildfly 8.2 and my HornetQ configuration looks like this:

            <hornetq-server>

                <persistence-enabled>true</persistence-enabled>

                <security-enabled>false</security-enabled>

                <journal-file-size>102400</journal-file-size>

                <journal-min-files>2</journal-min-files>

                <connectors>

                    <netty-connector name="netty" socket-binding="messaging"/>

                    <netty-connector name="netty-throughput" socket-binding="messaging-throughput">

                        <param key="batch-delay" value="50"/>

                    </netty-connector>

                    <in-vm-connector name="in-vm" server-id="0"/>

                </connectors>

                <acceptors>

                    <netty-acceptor name="netty" socket-binding="messaging"/>

                    <netty-acceptor name="netty-throughput" socket-binding="messaging-throughput">

                        <param key="batch-delay" value="50"/>

                        <param key="direct-deliver" value="false"/>

                    </netty-acceptor>

                    <in-vm-acceptor name="in-vm" server-id="0"/>

                </acceptors>

                <security-settings>

                    <security-setting match="#">

                        <permission type="send" roles="jms"/>

                        <permission type="consume" roles="jms"/>

                        <permission type="createNonDurableQueue" roles="jms"/>

                        <permission type="deleteNonDurableQueue" roles="jms"/>

                    </security-setting>

                </security-settings>

                <address-settings>

                    <address-setting match="#">

                        <dead-letter-address>jms.queue.DLQ</dead-letter-address>

                        <expiry-address>jms.queue.ExpiryQueue</expiry-address>

                        <redelivery-delay>0</redelivery-delay>

                        <max-size-bytes>10485760</max-size-bytes>

                        <address-full-policy>BLOCK</address-full-policy>

                        <message-counter-history-day-limit>10</message-counter-history-day-limit>

                    </address-setting>

                </address-settings>

                <jms-connection-factories>

                    <connection-factory name="InVmConnectionFactory">

                        <connectors>

                            <connector-ref connector-name="in-vm"/>

                        </connectors>

                        <entries>

                            <entry name="java:/ConnectionFactory"/>

                        </entries>

                    </connection-factory>

                    <connection-factory name="RemoteConnectionFactory">

                        <connectors>

                            <connector-ref connector-name="netty"/>

                        </connectors>

                        <entries>

                            <entry name="RemoteConnectionFactory"/>

                            <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>

                        </entries>

                    </connection-factory>

                    <pooled-connection-factory name="hornetq-ra">

                        <transaction mode="local"/>

                        <connectors>

                            <connector-ref connector-name="in-vm"/>

                        </connectors>

                        <entries>

                            <entry name="java:/JmsXA"/>

                            <entry name="java:jboss/DefaultJMSConnectionFactory"/>

                        </entries>

                    </pooled-connection-factory>

                </jms-connection-factories>

                <jms-destinations>...</jms-destinations>

            </hornetq-server>

Thanks

   Søren Hilmer

[jbertram]

I'm not aware of any single setting which turns off XA functionality for the entire broker.  What's your use-case?

The WARN in the log is coming from the XA transaction recovery manager which runs every 120 seconds or so to find orphaned XA transactions (i.e. XA transactions that were prepared but not committed).

[hilmer]

So the mention of hornetq in the WARN logs, is because the XA transaction recovery manager, uses hornetq internally, and not because the Hornet uses XA?

My use case is to speed up processing of the incoming messages, XA has a lot of overhead associated with it.

I get a feeling that you can turn it of on a more specific level than the entire broker, on what level is that and how is it done?

Best

Søren

[jbertram]

So the mention of hornetq in the WARN logs, is because the XA transaction recovery manager, uses hornetq internally, and not because the Hornet uses XA?

Not exactly.  HornetQ uses XA when required.  In other words it is an XA transaction resource manager and as such it is registered with the XA transaction recovery manager so that the XA transaction recovery manager inspects HornetQ every 120 seconds or so to see if there are any orphaned XA transactions.

My use case is to speed up processing of the incoming messages, XA has a lot of overhead associated with it.

I get a feeling that you can turn it of on a more specific level than the entire broker, on what level is that and how is it done?

Are your producers or consumers actually using XA transactions?  If so, that's where you should make your change.  HornetQ will only apply XA semantics in response to a client's request to do so.  It doesn't enforce XA semantics on any and/or all message operations.

[hilmer]

Thank you very much Justin, this pointed me in the right direction. I guess I was too focused on fixing this globally in the broker.

Best

  Søren