You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Rob Bugh (JIRA)" <ji...@apache.org> on 2008/05/05 22:09:43 UTC
[jira] Created: (AMQ-1710) Failing over in JDBC Master/Slave
topology does not preserve transaction state
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.
[jira] Issue Comment Edited: (AMQ-1710) Failing over in JDBC
Master/Slave topology does not preserve transaction state
Posted by "Mario Siegenthaler (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (AMQ-1710) Failing over in JDBC Master/Slave
topology does not preserve transaction state
Posted by "Mario Siegenthaler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mario Siegenthaler updated AMQ-1710:
------------------------------------
Attachment: AMQ-1710.patch
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.
[jira] Resolved: (AMQ-1710) Failing over in JDBC Master/Slave
topology does not preserve transaction state
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies resolved AMQ-1710.
-----------------------------
Resolution: Fixed
Patch code already applied
> 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
> Assignee: Rob Davies
> Fix For: 5.3.0
>
> 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.
[jira] Assigned: (AMQ-1710) Failing over in JDBC Master/Slave
topology does not preserve transaction state
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies reassigned AMQ-1710:
-------------------------------
Assignee: Rob Davies
> 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
> Assignee: Rob Davies
> Fix For: 5.3.0
>
> 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.
[jira] Commented: (AMQ-1710) Failing over in JDBC Master/Slave
topology does not preserve transaction state
Posted by "Vadim Katz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45367#action_45367 ]
Vadim Katz commented on AMQ-1710:
---------------------------------
Thank you for suggesting a patch, Mario.
I have applied it but received the following exception in the slave broker
{code}
008-09-03 14:49:58,835 [/127.0.0.1:4038] ERROR Service - Async error occurred: javax.jms.JMSException: Could not correlate acknowledgment with dispatched message: MessageAck {commandId = 3709, responseRequired = false, ackType = 0, consumerId = ID:VKATZ-XP1-3975-1220478455256-0:0:4:1, firstMessageId = null, lastMessageId = ID:VKATZ-XP1-3975-1220478455256-0:0:26:1:10, destination = queue://convert.input, transactionId = TX:ID:VKATZ-XP1-3975-1220478455256-0:0:10, messageCount = 1}
javax.jms.JMSException: Could not correlate acknowledgment with dispatched message: MessageAck {commandId = 3709, responseRequired = false, ackType = 0, consumerId = ID:VKATZ-XP1-3975-1220478455256-0:0:4:1, firstMessageId = null, lastMessageId = ID:VKATZ-XP1-3975-1220478455256-0:0:26:1:10, destination = queue://convert.input, transactionId = TX:ID:VKATZ-XP1-3975-1220478455256-0:0:10, messageCount = 1}
at org.apache.activemq.broker.region.PrefetchSubscription.acknowledge(PrefetchSubscription.java:279)
at org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:364)
at org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:470)
at org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:194)
at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:73)
at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:73)
at org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:84)
at org.apache.activemq.broker.TransportConnection.processMessageAck(TransportConnection.java:443)
at org.apache.activemq.command.MessageAck.visit(MessageAck.java:196)
at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:292)
at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:180)
at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:68)
at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:143)
at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:206)
at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84)
at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:196)
at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:183)
at java.lang.Thread.run(Thread.java:619)
I've tested it with amq-5.1.0 and spring-2.5.5 with locally transacted session. Also, even though the slave broker becomes active it hangs after throwing the exception and stops accepting new connections.
thanks,
vadim
{code}
> 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.
[jira] Commented: (AMQ-1710) Failing over in JDBC Master/Slave
topology does not preserve transaction state
Posted by "Mario Siegenthaler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45581#action_45581 ]
Mario Siegenthaler commented on AMQ-1710:
-----------------------------------------
Warning: Do not apply my patch before AMQ-1925 is resolved, else things will go badly wrong (undelivered messages are deleted from the store)
> 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.
[jira] Issue Comment Edited: (AMQ-1710) Failing over in JDBC
Master/Slave topology does not preserve transaction state
Posted by "Vadim Katz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45367#action_45367 ]
vadimos edited comment on AMQ-1710 at 9/3/08 3:07 PM:
---------------------------------------------------------
Thank you for suggesting a patch, Mario.
I have applied it but received the following exception in the slave broker
{code}
008-09-03 14:49:58,835 [/127.0.0.1:4038] ERROR Service - Async error occurred: javax.jms.JMSException: Could not correlate acknowledgment with dispatched message: MessageAck {commandId = 3709, responseRequired = false, ackType = 0, consumerId = ID:VKATZ-XP1-3975-1220478455256-0:0:4:1, firstMessageId = null, lastMessageId = ID:VKATZ-XP1-3975-1220478455256-0:0:26:1:10, destination = queue://convert.input, transactionId = TX:ID:VKATZ-XP1-3975-1220478455256-0:0:10, messageCount = 1}
javax.jms.JMSException: Could not correlate acknowledgment with dispatched message: MessageAck {commandId = 3709, responseRequired = false, ackType = 0, consumerId = ID:VKATZ-XP1-3975-1220478455256-0:0:4:1, firstMessageId = null, lastMessageId = ID:VKATZ-XP1-3975-1220478455256-0:0:26:1:10, destination = queue://convert.input, transactionId = TX:ID:VKATZ-XP1-3975-1220478455256-0:0:10, messageCount = 1}
at org.apache.activemq.broker.region.PrefetchSubscription.acknowledge(PrefetchSubscription.java:279)
at org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:364)
at org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:470)
at org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:194)
at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:73)
at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:73)
at org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:84)
at org.apache.activemq.broker.TransportConnection.processMessageAck(TransportConnection.java:443)
at org.apache.activemq.command.MessageAck.visit(MessageAck.java:196)
at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:292)
at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:180)
at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:68)
at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:143)
at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:206)
at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84)
at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:196)
at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:183)
at java.lang.Thread.run(Thread.java:619)
{code}
I've tested it with amq-5.1.0 and spring-2.5.5 with locally transacted session. Also, even though the slave broker becomes active it hangs after throwing the exception and stops accepting new connections.
thanks,
vadim
was (Author: vadimos):
Thank you for suggesting a patch, Mario.
I have applied it but received the following exception in the slave broker
{code}
008-09-03 14:49:58,835 [/127.0.0.1:4038] ERROR Service - Async error occurred: javax.jms.JMSException: Could not correlate acknowledgment with dispatched message: MessageAck {commandId = 3709, responseRequired = false, ackType = 0, consumerId = ID:VKATZ-XP1-3975-1220478455256-0:0:4:1, firstMessageId = null, lastMessageId = ID:VKATZ-XP1-3975-1220478455256-0:0:26:1:10, destination = queue://convert.input, transactionId = TX:ID:VKATZ-XP1-3975-1220478455256-0:0:10, messageCount = 1}
javax.jms.JMSException: Could not correlate acknowledgment with dispatched message: MessageAck {commandId = 3709, responseRequired = false, ackType = 0, consumerId = ID:VKATZ-XP1-3975-1220478455256-0:0:4:1, firstMessageId = null, lastMessageId = ID:VKATZ-XP1-3975-1220478455256-0:0:26:1:10, destination = queue://convert.input, transactionId = TX:ID:VKATZ-XP1-3975-1220478455256-0:0:10, messageCount = 1}
at org.apache.activemq.broker.region.PrefetchSubscription.acknowledge(PrefetchSubscription.java:279)
at org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:364)
at org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:470)
at org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:194)
at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:73)
at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:73)
at org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:84)
at org.apache.activemq.broker.TransportConnection.processMessageAck(TransportConnection.java:443)
at org.apache.activemq.command.MessageAck.visit(MessageAck.java:196)
at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:292)
at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:180)
at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:68)
at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:143)
at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:206)
at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84)
at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:196)
at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:183)
at java.lang.Thread.run(Thread.java:619)
I've tested it with amq-5.1.0 and spring-2.5.5 with locally transacted session. Also, even though the slave broker becomes active it hangs after throwing the exception and stops accepting new connections.
thanks,
vadim
{code}
> 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.
[jira] Commented: (AMQ-1710) Failing over in JDBC Master/Slave
topology does not preserve transaction state
Posted by "Dhirendra Rai (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49441#action_49441 ]
Dhirendra Rai commented on AMQ-1710:
------------------------------------
Hi,
I am using Activemq 5.1.0 and using the master slave configuration with shared file system.
Activemq: Exception is appearing for pending requests when master goes down and slave gets up.
ERROR Service - Async error occurred: javax.jms.JMSException: Could not correlate acknowledgment with dispatched message: MessageAck {commandId = 192281, responseRequired = false, ackType = 3, consumerId = ID:mapgl3-49587-1233655489869-0:0:18:1, firstMessageId = null, lastMessageId = ID:mapgl3-49587-1233655489869-0:8:2:1:603, destination = queue://sybase.delivery.queue, transactionId = null, messageCount = 1}
javax.jms.JMSException: Could not correlate acknowledgment with dispatched message: MessageAck {commandId = 192281, responseRequired = false, ackType = 3, consumerId = ID:mapgl3-49587-1233655489869-0:0:18:1, firstMessageId = null, lastMessageId = ID:mapgl3-49587-1233655489869-0:8:2:1:603, destination = queue://sybase.delivery.queue, transactionId = null, messageCount = 1}
at org.apache.activemq.broker.region.PrefetchSubscription.acknowledge(PrefetchSubscription.java:307)
at org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:364)
at org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:470)
at org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:194)
at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:73)
at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:73)
at org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:84)
at org.apache.activemq.broker.TransportConnection.processMessageAck(TransportConnection.java:443)
at org.apache.activemq.command.MessageAck.visit(MessageAck.java:196)
at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:292)
at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:180)
at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:68)
at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:143)
at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:206)
at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84)
at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:196)
at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:183)
at java.lang.Thread.run(Thread.java:595)
> 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
> Assignee: Rob Davies
> Fix For: 5.2.0
>
> 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.
[jira] Commented: (AMQ-1710) Failing over in JDBC Master/Slave
topology does not preserve transaction state
Posted by "Rob Bugh (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (AMQ-1710) Failing over in JDBC Master/Slave
topology does not preserve transaction state
Posted by "Rob Bugh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=42545#action_42545 ]
Rob Bugh commented on AMQ-1710:
-------------------------------
I've attached a test case that implements the recreate steps described above.
> 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.