[
https://issues.apache.org/activemq/browse/AMQ-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=42546#action_42546
]
Rob Bugh commented on AMQ-1710:
-------------------------------
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.
> Failing over in JDBC Master/Slave topology does not preserve transaction state
> ------------------------------------------------------------------------------
>
> Key: AMQ-1710
> URL: https://issues.apache.org/activemq/browse/AMQ-1710
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, Transport
> Affects Versions: 4.1.2
> Environment: Tested on 4.1.1 and 4.1.2
> Reporter: Rob Bugh
> Attachments: FailoverTest.java
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
