Uploaded image for project: 'JBoss A-MQ'
  1. JBoss A-MQ
  2. ENTMQ-1627

Incorrect TransactionRolledBackException in failover protocol

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Won't Do
    • Icon: Major Major
    • None
    • JBoss A-MQ 6.2.1
    • failover
    • None
    • Hide
      1. Download attached reproducer
      2. run the it with maven: mvn clean install -Dmessage.count=20000 -Drestart.timeout=5
        • reproducer will start both broker and client
        • producer repeats the transaction if TransactionRolledBackException is thrown on commit
      3. number of messages in the queue will be larger than expected
        • It may happen that test will succeed since the incorrect TransactionRolledBackException depends on the timing of broker restart so you may want to run the test with another message count or restart timeout.
      Show
      Download attached reproducer run the it with maven: mvn clean install -Dmessage.count=20000 -Drestart.timeout=5 reproducer will start both broker and client producer repeats the transaction if TransactionRolledBackException is thrown on commit number of messages in the queue will be larger than expected It may happen that test will succeed since the incorrect TransactionRolledBackException depends on the timing of broker restart so you may want to run the test with another message count or restart timeout.

      I have a producer which connects to the broker using failover protocol and sends messages in small transactions. When the broker fails and it is restarted the producer throws TransactionRolledBackException and transaction is rolled back. Sometimes the TransactionRolledBackException is thrown by the producer but the transactions is already commited on broker side. So the client has no chance to find out whether the transaction was really rolled back or not.

      Is there any way for the client to find out whether the transaction was rolled back or it was already commited? Because without that information client can't know if it should resend messages. So client has two options:

      • always resend messages on TransactionRolledBackException risking duplicate messages on the broker
      • always ignore the TransactionRolledBackException and risking lost messages

      logs

      client side throws exception
      2016-04-06 17:09:02 WARN  ProducerWorker:64 - Exception thrown during commit: 239
      javax.jms.TransactionRolledBackException: Transaction completion in doubt due to failover. Forcing rollback of TX:ID:localhost.localdomain-34468-1459955340171-3:1:240
              at org.apache.activemq.state.ConnectionStateTracker.restoreTransactions(ConnectionStateTracker.java:254)
              at org.apache.activemq.state.ConnectionStateTracker.restore(ConnectionStateTracker.java:191)
              at org.apache.activemq.transport.failover.FailoverTransport.restoreTransport(FailoverTransport.java:852)
              at org.apache.activemq.transport.failover.FailoverTransport.doReconnect(FailoverTransport.java:1030)
              at org.apache.activemq.transport.failover.FailoverTransport$2.iterate(FailoverTransport.java:149)
              at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:133)
              at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48)
              at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
              at java.lang.Thread.run(Thread.java:745)
      
      
      broker commited the transaction
      2016-04-06 17:09:02 DEBUG org.apache.activemq.transaction.LocalTransaction:48 - commit: TX:ID:localhost.localdomain-34468-1459955340171-3:1:240 syncCount: 10
      

              Unassigned Unassigned
              knetl.j@gmail.com Jakub Knetl (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: