Failing over in JDBC Master/Slave topology does not preserve transaction state

• Key: AMQ-1710
• Type: Bug
• Status: Open
• Priority: Major
• Assignee: Unassigned
• Reporter: Rob Bugh
• Component/s: Transport, Broker
• Affects Version/s: 4.1.2

Description

Recreate steps:

1) Start two brokers in JDBC Master/Slave topology

2) Create an app that puts two or more messages in a queue (two messages are sufficient). Give each message a JMXGroupID to force them to go to the same consumer.

3) Create another app that creates two connection to the broker and on each connection creates a session and a consumer with a unique clientID. Each should attempt to consume messages from the queue defined above.

4) Run the app and when the first message is consumed stop the master. Failover will occur and the slave becomes the new master.

5) Notice that when the transport resumes in the client that received the first message an exception like the following is thrown:
javax.jms.JMSException: Transaction 'TX:ID:HOSTNAME-3289-1210016021661-0:1:1' has not been started.

6) Notice that the second consumer now recieves both messages.

Comments

[Rob Bugh]

I've attached a test case that implements the recreate steps described above.

[Rob Bugh]

Forgot to mention the session is transactional. The recreate steps should be amended as follows:
Recreate steps:

1) Start two brokers in JDBC Master/Slave topology

2) Create an app that puts two or more messages in a queue (two messages are sufficient). Give each message a JMXGroupID to force them to go to the same consumer.

3) Create another app that creates two connections to the broker and on each connection creates a transactional session and a consumer with a unique clientID. Each client consumes messages from the queue defined above waits 60 seconds then commits the transaction.

4) Run the app and when the first message is consumed stop the master before the commit occurs. Failover will occur and the slave becomes the new master.

5) Notice that when the transport resumes in the client that received the first message an exception like the following is thrown:
javax.jms.JMSException: Transaction 'TX:ID:HOSTNAME-3289-1210016021661-0:1:1' has not been started.

6) Notice that the second consumer now recieves both messages.

I expected the transaction (and the JMXGroupID) to survive across the failover and thus the consumer that retrieves the first message retrieves the seconds one as well.