2 Replies Latest reply on Mar 15, 2010 3:33 PM by Clebert Suconic

    XA configuration for RA in TCK

    Jeff Mesnil Master

      I'm having new failures now that Clebert has fixed https://jira.jboss.org/jira/browse/HORNETQ-328 to prevent to do any work on a XA session when there is no enlisted transaction.

       

      For example, there is a test checking autoack. the test is pretty simple:

       

      - create a non-transacted auto-acked session

      - send 2 messages

      - receive the 1 first one

      - call session.recover

      - receive the 2nd one

       

      The test pass when run in a client context but fails when run in a ejb/jsp/servlet context (using the resource adapter).

      The test fails because the messages are not sent when checking XA on the server side:

       

      18:17:08,431 ERROR [org.hornetq.core.protocol.core.ServerSessionPacketHandler] Caught XA exception: org.hornetq.core.exception.HornetQXAException: Invalid transaction state

      at org.hornetq.core.server.impl.ServerSessionImpl.doSend(ServerSessionImpl.java:1255)

      at org.hornetq.core.server.impl.ServerSessionImpl.send(ServerSessionImpl.java:950)

      at org.hornetq.core.protocol.core.ServerSessionPacketHandler.handlePacket(ServerSessionPacketHandler.java:435)

      at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:464)

      at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:439)

      at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:405)

      at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:403)

      at org.hornetq.core.remoting.impl.invm.InVMConnection$1.run(InVMConnection.java:131)

      at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:96)

      at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

      at java.lang.Thread.run(Thread.java:637)

       

      The issue is that the session is created as a XA session and it is now no longer possible to send messages on a XA session if there is no enlisted transaction.

       

      The configuration corresponding to the CF is in hornetq.sar/tck-connection-factories.xml:

       

         <tx-connection-factory>

            <jndi-name>QueueConnectionFactory</jndi-name>

            <rar-name>jms-ra.rar</rar-name>

            <connection-definition>org.hornetq.ra.HornetQRAConnectionFactory</connection-definition>

            <xa-transaction/>

            <config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/DefaultJMSProvider</config-property>

            <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Queue</config-property>

            <application-managed-security/>

         </tx-connection-factory>

       

      I copied it straight from JBM configuration for the TCK (which also had the <xa-transaction/> element).

       

      Removing the <xa-transaction/> does not change anything since our resource adapter will create XA sessions by default!

       

      Next step is to change the default value of XA in jms-ra.rar/META-INF/ra.xml:

       

            <config-property>

              <description>Use XA?</description>

              <config-property-name>UseXA</config-property-name>

              <config-property-type>java.lang.Boolean</config-property-type>

              <config-property-value>false</config-property-value>

            </config-property>

       

      This way, the sessions created by the RA no longer uses XA by default.

       

      And now the test passes.

       

      There are things I don't understand and people with more background on our RA and the TCK could help me.

       

      - Why do we default XA to true for HornetQ RA? aiui, JBM 1.4 does not default to XA.

      => it'd be better to *not* default to XA and use XA only when the user explicitely requires it

       

      - Why did we declare all the connection factories used by the TCK with <xa-transaction/>?

        I don't see a reason why looking at the TCK code or doc... It was working with JBM as it was allowing

        to do stuff on XA session even when there was no enlisted TX. Now that HornetQ has a stricter behavior,

        using XA for doing non-transacted work does not work anymore?

       

      - Is it valid to do non-tx work on a XA session when there is no tx?

      It's already been discussed for JBM (http://community.jboss.org/thread/81674?start=30&tstart=0) and the answer at that time was that it

      was ok.

      I'm looking at the JEE, JCA specs to find a definitive answer but I did not find it yet.

        • 1. Re: XA configuration for RA in TCK
          Tim Fox Master

          I don't like the idea of us treating work on an XA session as non transacted when the session is not enlisted.

           

          The JCA adapter can avoid this internally by just using a non XA, normal session if it hasn't been enlisted.

          • 2. Re: XA configuration for RA in TCK
            Clebert Suconic Master

            Tim said: "I don't like the idea..."

             

            +1

             

            As Tim was saying...    "..of us treating work on an XA session as non transacted when the session is not enlisted."

             

             

            That wouldn't work anyway...

             

            Say the transaction is rolled back because of a timeout (say the user configured a timeout on the transaction).

             

            What will happen is the TM will send end(success) and call rollback. At this point there is nothing enlisted on the session.. what means we would just treat it as non-transacted when it should be consider an invalid state TX.

             

            It would be possible to write a broken tests even with JBM 1.4. The only reason the integration test worked on the AS is because the RA is always checking the state of the current transaction.