activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mario Siegenthaler (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (AMQ-1710) Failing over in JDBC Master/Slave topology does not preserve transaction state
Date Tue, 02 Sep 2008 15:17:52 GMT

    [ https://issues.apache.org/activemq/browse/AMQ-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45325#action_45325
] 

msiegenthaler edited comment on AMQ-1710 at 9/2/08 8:16 AM:
-----------------------------------------------------------------

I propose the attached patch for the issue.

It allows producers to survive a failover-situation, all my tests so far were successful (all
of them run with JDBC-Master/Slave).

What I did: During the recovery of the transaction I issue a "begin transaction" command (TransactionInfo
with TransactionInfo.BEGIN). [actually I add it to the transaction-commands on processBeginTransaction,
but it gets issued in the recovery]. So all the recovery-commands following on the transaction
(like send message or commit-tx) now can find their transaction and do no longer fail with
"transaction not started".

I'm not a 100-percent sure what happens in a XA-situation as I didn't have the necessary setup.
I suspect it works fine, but with XA you can never be sure.

(the patch applies to version 5.1.0, the problem is the same in 4.1 and 5.x)

      was (Author: msiegenthaler):
    I propose the attached patch for the issue.

It allows producers to survive a failover-situation, all my tests so far were successful (all
of them run with JDBC-Master/Slave).

What I did: During the recovery of the transaction I issue a "begin transaction" command (TransactionInfo
with TransactionInfo.BEGIN). [actually I add it to the transaction-commands on processBeginTransaction,
but it gets issued in the recovery]. So all the recovery-commands following on the transaction
(like send message or commit-tx) now can find their transaction and do no longer fail with
"transaction not started".

I'm not a 100-percent sure what happens in a XA-situation as I didn't have the necessary setup.
I suspect it works fine, but with XA you can never be sure.
  
> 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: AMQ-1710.patch, 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.


Mime
View raw message