[jira] [Updated] (AMQNET-413) Message consumers do not respect DTC Transactions correctly
[
https://issues.apache.org/jira/browse/AMQNET-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remo Gloor updated AMQNET-413:
--
Summary: Message consumers do not respect DTC Transactions correctly (was:
Message producers do not respect DTC Transactions correctly)
> Message consumers do not respect DTC Transactions correctly
> ---
>
> Key: AMQNET-413
> URL: https://issues.apache.org/jira/browse/AMQNET-413
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ
>Reporter: Remo Gloor
>Assignee: Jim Gomes
> Attachments: AMQNET-413.patch,
> AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
> AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
> allDTCImprovments.patch
>
>
> When consuming messages in a transaction and sending new ones during
> processing of that message and the transaction is rolled back and commited on
> retry the number of published messages should be equal to the received one.
> But the number of sent message is bigger than the number of received ones.
> This means some of the message sends are not rolled back others are.
> EDIT: Further analysis have shown that the TransactionContext.TransactionId
> is null when sending eventhough a transaction is in progress and not yet
> completed. It must incorrectly be assigned to null somewhere.
> The following application demonstrates the problem when enqueuing 100+
> messages to foo.bar
> class Program
> {
> private static INetTxSession activeMqSession;
> private static IMessageConsumer consumer;
> private static INetTxConnection connection;
> static void Main(string[] args)
> {
> using (connection = CreateActiveMqConnection())
> using (activeMqSession = connection.CreateNetTxSession())
> using (consumer =
> activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
> "queue://foo.bar")))
> {
> connection.Start();
> while (true)
> {
> try
> {
> using (TransactionScope scoped = new
> TransactionScope(TransactionScopeOption.RequiresNew))
> {
> IMessage msg = null;
> while (msg == null)
> {
> msg = consumer.ReceiveNoWait();
> }
> OnMessage(msg);
> scoped.Complete();
> }
> }
> catch(Exception exception) {}
> }
> }
> }
> private static INetTxConnection CreateActiveMqConnection()
> {
> var connectionFactory = new
> Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
> {
> AcknowledgementMode = AcknowledgementMode.Transactional
> };
> return connectionFactory.CreateNetTxConnection();
> }
> private static void OnMessage(IMessage message)
> {
> var x = new TestSinglePhaseCommit();
> Console.WriteLine("Processing message {0} in transaction {1} -
> {2}", message.NMSMessageId,
> Transaction.Current.TransactionInformation.LocalIdentifier,
> Transaction.Current.TransactionInformation.DistributedIdentifier);
> var session2 = activeMqSession;
> {
> Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
> EnlistmentOptions.None);
> using (var producer =
> session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
> {
> producer.Send(new ActiveMQTextMessage("foo"));
> }
> if (!message.NMSRedelivered) throw new Exception();
> }
> }
> }
> internal class TestSinglePhaseCommit : ISinglePhaseNotification
> {
> public void Prepare(PreparingEnlistment preparingEnlistment)
> {
> preparingEnlistment.Prepared();
> }
> public void Commit(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void Rollback(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void InDoubt(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void SinglePhaseCommit(SinglePhaseEnlistment
> singlePhaseEnlistment)
> {
> singlePhaseEnlistment.Committed();
> }
> }
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (AMQNET-413) Message producers do not respect DTC Transactions correctly
[
https://issues.apache.org/jira/browse/AMQNET-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848157#comment-13848157
]
Remo Gloor commented on AMQNET-413:
---
I don't understand what you mean. The only call on consumer I see is
consumer.Receive(TimeSpan.FromMilliseconds(1)) as ITextMessage;
I'm pretty sure that this is on the consumer. Did you use the latest patch file?
For the other point that seems to be a mistake. Obviously it should be consumer
not producer. Sorry about that.
> Message producers do not respect DTC Transactions correctly
> ---
>
> Key: AMQNET-413
> URL: https://issues.apache.org/jira/browse/AMQNET-413
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ
>Reporter: Remo Gloor
>Assignee: Jim Gomes
> Attachments: AMQNET-413.patch,
> AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
> AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
> allDTCImprovments.patch
>
>
> When consuming messages in a transaction and sending new ones during
> processing of that message and the transaction is rolled back and commited on
> retry the number of published messages should be equal to the received one.
> But the number of sent message is bigger than the number of received ones.
> This means some of the message sends are not rolled back others are.
> EDIT: Further analysis have shown that the TransactionContext.TransactionId
> is null when sending eventhough a transaction is in progress and not yet
> completed. It must incorrectly be assigned to null somewhere.
> The following application demonstrates the problem when enqueuing 100+
> messages to foo.bar
> class Program
> {
> private static INetTxSession activeMqSession;
> private static IMessageConsumer consumer;
> private static INetTxConnection connection;
> static void Main(string[] args)
> {
> using (connection = CreateActiveMqConnection())
> using (activeMqSession = connection.CreateNetTxSession())
> using (consumer =
> activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
> "queue://foo.bar")))
> {
> connection.Start();
> while (true)
> {
> try
> {
> using (TransactionScope scoped = new
> TransactionScope(TransactionScopeOption.RequiresNew))
> {
> IMessage msg = null;
> while (msg == null)
> {
> msg = consumer.ReceiveNoWait();
> }
> OnMessage(msg);
> scoped.Complete();
> }
> }
> catch(Exception exception) {}
> }
> }
> }
> private static INetTxConnection CreateActiveMqConnection()
> {
> var connectionFactory = new
> Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
> {
> AcknowledgementMode = AcknowledgementMode.Transactional
> };
> return connectionFactory.CreateNetTxConnection();
> }
> private static void OnMessage(IMessage message)
> {
> var x = new TestSinglePhaseCommit();
> Console.WriteLine("Processing message {0} in transaction {1} -
> {2}", message.NMSMessageId,
> Transaction.Current.TransactionInformation.LocalIdentifier,
> Transaction.Current.TransactionInformation.DistributedIdentifier);
> var session2 = activeMqSession;
> {
> Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
> EnlistmentOptions.None);
> using (var producer =
> session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
> {
> producer.Send(new ActiveMQTextMessage("foo"));
> }
> if (!message.NMSRedelivered) throw new Exception();
> }
> }
> }
> internal class TestSinglePhaseCommit : ISinglePhaseNotification
> {
> public void Prepare(PreparingEnlistment preparingEnlistment)
> {
> preparingEnlistment.Prepared();
> }
> public void Commit(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void Rollback(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void InDoubt(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void S
[jira] [Commented] (AMQ-4837) LevelDB corrupted in AMQ cluster
[
https://issues.apache.org/jira/browse/AMQ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13834918#comment-13834918
]
Remo Gloor commented on AMQ-4837:
-
https://issues.apache.org/jira/browse/AMQ-4882
is the unclustered version of this problem. I can reproduce this by 100% just
by starting some client that processes and enqueues messages while
starting/stopping AMQ. After some restarts AMQ won't start anymore and the log
contains the exception posted by others in this issue.
> LevelDB corrupted in AMQ cluster
>
>
> Key: AMQ-4837
> URL: https://issues.apache.org/jira/browse/AMQ-4837
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0
> Environment: CentOS, Linux version 2.6.32-71.29.1.el6.x86_64
> java-1.7.0-openjdk.x86_64/java-1.6.0-openjdk.x86_64
> zookeeper-3.4.5.2
>Reporter: Guillaume
>Assignee: Hiram Chirino
>Priority: Critical
> Attachments: LevelDBCorrupted.zip, activemq.xml
>
>
> I have clustered 3 ActiveMQ instances using replicated leveldb and zookeeper.
> When performing some tests using Web UI, I can across issues that appears to
> corrupt the leveldb data files.
> The issue can be replicated by performing the following steps:
> 1.Start 3 activemq nodes.
> 2.Push a message to the master (Node1) and browse the queue using the web
> UI
> 3.Stop master node (Node1)
> 4.Push a message to the new master (Node2) and browse the queue using the
> web UI. Message summary and queue content ok.
> 5.Start Node1
> 6.Stop master node (Node2)
> 7.Browse the queue using the web UI on new master (Node3). Message
> summary ok however when clicking on the queue, no message details. An error
> (see below) is logged by the master, which attempts a restart.
> From this point, the database appears to be corrupted and the same error
> occurs to each node infinitely (shutdown/restart). The only way around is to
> stop the nodes and clear the data files.
> However when a message is pushed between step 5 and 6, the error doesn’t
> occur.
> =
> Leveldb configuration on the 3 instances:
>
> directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zkserver:2181"
> zkPath="/activemq/leveldb-stores"
> />
>
> =
> The error is:
> INFO | Stopping BrokerService[localhost] due to exception, java.io.IOException
> java.io.IOException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:543)
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:974)
> at
> org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1270)
> at
> org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1194)
> at
> org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:708)
>at
> org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:741)
> at
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:106)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:258)
> at
> org.apache.activemq.broker.region.cursors.AbstractStoreCursor.reset(AbstractStoreCursor.java:108)
> at
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.reset(StoreQueueCursor.java:157)
> at
> org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1875)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2086)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1581)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1198)
> at
> org.apache.activemq.leve
[jira] [Updated] (AMQ-4882) LevelDB can get to a corrupt state
[ https://issues.apache.org/jira/browse/AMQ-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQ-4882: Attachment: TestClient.zip > LevelDB can get to a corrupt state > -- > > Key: AMQ-4882 > URL: https://issues.apache.org/jira/browse/AMQ-4882 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-leveldb-store >Affects Versions: 5.9.0 >Reporter: Remo Gloor >Priority: Critical > Attachments: TestClient.zip, activemq.log > > > A consumer/producer with failover transport is connected to AMQ and processes > messages in XA Transactions. When AMQ is restarted is can happen that LevelDB > gets to a corrupt state so that AMQ can not be started anymore without > deletind the database. > Reproduction: > - Configure AMQ with LevelDB > - Run the attached TestClient > - Restart AMQ several times. At some time it won't start anymore and produced > the exception in the attached log file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQ-4882) LevelDB can get to a corrupt state
[ https://issues.apache.org/jira/browse/AMQ-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQ-4882: Attachment: (was: TestClient.zip) > LevelDB can get to a corrupt state > -- > > Key: AMQ-4882 > URL: https://issues.apache.org/jira/browse/AMQ-4882 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-leveldb-store >Affects Versions: 5.9.0 >Reporter: Remo Gloor >Priority: Critical > Attachments: TestClient.zip, activemq.log > > > A consumer/producer with failover transport is connected to AMQ and processes > messages in XA Transactions. When AMQ is restarted is can happen that LevelDB > gets to a corrupt state so that AMQ can not be started anymore without > deletind the database. > Reproduction: > - Configure AMQ with LevelDB > - Run the attached TestClient > - Restart AMQ several times. At some time it won't start anymore and produced > the exception in the attached log file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (AMQNET-462) Failover transport: Deduplication algorithm is wrong (1)
[ https://issues.apache.org/jira/browse/AMQNET-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13822481#comment-13822481 ] Remo Gloor edited comment on AMQNET-462 at 11/14/13 2:36 PM: - My unittest and fixes for this problem rely other patches that are not applied since 9 months. I won't spend the time to reduce them to the current trunks version and separate the various problems from each other into small patches because I have the feeling that my help isn't really apprechiated and there is little to know guarantee that such patches will be applied anyway. So it's just waste of time. This is just to tell you that you have a problem. I fixed this and various other problems related to the new failover implementation for myself already. Applying patches that are open for 9 months would be a good start to work together from your side. was (Author: remogloor): My unittest and fixes for this problem rely other patches that are not applied since 9 months. I won't spend the time to reduce them to the current trunks version and separate the various problems from each other into small patches because I have the feeling that my help isn't really apprechiated and there is little to know guarantee that such patches will be applied anyway. So it's just waste of time. This is just to tell you that you have a problem. I fixed it for myself already. Applying patches that are open for 9 months would be a good start to work together from your side. > Failover transport: Deduplication algorithm is wrong (1) > > > Key: AMQNET-462 > URL: https://issues.apache.org/jira/browse/AMQNET-462 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: Remo Gloor >Assignee: Jim Gomes > > 1. Create and start consumer > 2. Messages are delivered and queued in unconsumed messages > 3. Listener is added > 4. Messages are Redispatched > 5. Messages are considered duplicates > Succestion: > Have a cleare state of messages in the unconsumed messages. Either they > should be in the connections duplicate list or not. > If they are in the in the dup list. then rollback dup whenever a message is > redispatched. > If not check dup before deliver to message to the client. (Receive/Deliver to > Listener) > This makes it much easier to get a correct code then currently where > unconsumed messages can either be in the dup list or not. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQNET-462) Failover transport: Deduplication algorithm is wrong (1)
[ https://issues.apache.org/jira/browse/AMQNET-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13822481#comment-13822481 ] Remo Gloor commented on AMQNET-462: --- My unittest and fixes for this problem rely other patches that are not applied since 9 months. I won't spend the time to reduce them to the current trunks version and separate the various problems from each other into small patches because I have the feeling that my help isn't really apprechiated and there is little to know guarantee that such patches will be applied anyway. So it's just waste of time. This is just to tell you that you have a problem. I fixed it for myself already. Applying patches that are open for 9 months would be a good start to work together from your side. > Failover transport: Deduplication algorithm is wrong (1) > > > Key: AMQNET-462 > URL: https://issues.apache.org/jira/browse/AMQNET-462 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: Remo Gloor >Assignee: Jim Gomes > > 1. Create and start consumer > 2. Messages are delivered and queued in unconsumed messages > 3. Listener is added > 4. Messages are Redispatched > 5. Messages are considered duplicates > Succestion: > Have a cleare state of messages in the unconsumed messages. Either they > should be in the connections duplicate list or not. > If they are in the in the dup list. then rollback dup whenever a message is > redispatched. > If not check dup before deliver to message to the client. (Receive/Deliver to > Listener) > This makes it much easier to get a correct code then currently where > unconsumed messages can either be in the dup list or not. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQNET-463) previouslyDeliveredMessages.Add() does not change value
Remo Gloor created AMQNET-463: - Summary: previouslyDeliveredMessages.Add() does not change value Key: AMQNET-463 URL: https://issues.apache.org/jira/browse/AMQNET-463 Project: ActiveMQ .Net Issue Type: Bug Reporter: Remo Gloor Assignee: Jim Gomes MessageConsumer uses previouslyDeliveredMessages.Add() When the value exists it won't change that value. Hence the whole algorithm based on previouslyDeliveredMessages won't work atm. Use assignment instead previouslyDeliveredMessages[messageId] = X; -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQNET-462) Failover transport: Deduplication algorithm is wrong (1)
[ https://issues.apache.org/jira/browse/AMQNET-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-462: -- Description: 1. Create and start consumer 2. Messages are delivered and queued in unconsumed messages 3. Listener is added 4. Messages are Redispatched 5. Messages are considered duplicates Succestion: Have a cleare state of messages in the unconsumed messages. Either they should be in the connections dupplicate list or not. If they are in the in the dup list. then rollback dup whenever a message is redispatched. If not check dup before deliver to message to the client. (Receive/Deliver to Listener) This makes it much easier to get a correct code then currently where unconsumed messages can either be in the dup list or not. was: 1. Create and start consumer 2. Messages are delivered and queued in unconsumed messages 3. Listener is added 4. Messages are Redispatched 5. Messages are considered duplicates > Failover transport: Deduplication algorithm is wrong (1) > > > Key: AMQNET-462 > URL: https://issues.apache.org/jira/browse/AMQNET-462 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: Remo Gloor >Assignee: Jim Gomes > > 1. Create and start consumer > 2. Messages are delivered and queued in unconsumed messages > 3. Listener is added > 4. Messages are Redispatched > 5. Messages are considered duplicates > Succestion: > Have a cleare state of messages in the unconsumed messages. Either they > should be in the connections dupplicate list or not. > If they are in the in the dup list. then rollback dup whenever a message is > redispatched. > If not check dup before deliver to message to the client. (Receive/Deliver to > Listener) > This makes it much easier to get a correct code then currently where > unconsumed messages can either be in the dup list or not. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQNET-462) Failover transport: Deduplication algorithm is wrong (1)
[ https://issues.apache.org/jira/browse/AMQNET-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-462: -- Description: 1. Create and start consumer 2. Messages are delivered and queued in unconsumed messages 3. Listener is added 4. Messages are Redispatched 5. Messages are considered duplicates Succestion: Have a cleare state of messages in the unconsumed messages. Either they should be in the connections duplicate list or not. If they are in the in the dup list. then rollback dup whenever a message is redispatched. If not check dup before deliver to message to the client. (Receive/Deliver to Listener) This makes it much easier to get a correct code then currently where unconsumed messages can either be in the dup list or not. was: 1. Create and start consumer 2. Messages are delivered and queued in unconsumed messages 3. Listener is added 4. Messages are Redispatched 5. Messages are considered duplicates Succestion: Have a cleare state of messages in the unconsumed messages. Either they should be in the connections dupplicate list or not. If they are in the in the dup list. then rollback dup whenever a message is redispatched. If not check dup before deliver to message to the client. (Receive/Deliver to Listener) This makes it much easier to get a correct code then currently where unconsumed messages can either be in the dup list or not. > Failover transport: Deduplication algorithm is wrong (1) > > > Key: AMQNET-462 > URL: https://issues.apache.org/jira/browse/AMQNET-462 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: Remo Gloor >Assignee: Jim Gomes > > 1. Create and start consumer > 2. Messages are delivered and queued in unconsumed messages > 3. Listener is added > 4. Messages are Redispatched > 5. Messages are considered duplicates > Succestion: > Have a cleare state of messages in the unconsumed messages. Either they > should be in the connections duplicate list or not. > If they are in the in the dup list. then rollback dup whenever a message is > redispatched. > If not check dup before deliver to message to the client. (Receive/Deliver to > Listener) > This makes it much easier to get a correct code then currently where > unconsumed messages can either be in the dup list or not. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQNET-462) Failover transport: Deduplication algorithm is wrong (1)
Remo Gloor created AMQNET-462: - Summary: Failover transport: Deduplication algorithm is wrong (1) Key: AMQNET-462 URL: https://issues.apache.org/jira/browse/AMQNET-462 Project: ActiveMQ .Net Issue Type: Bug Reporter: Remo Gloor Assignee: Jim Gomes 1. Create and start consumer 2. Messages are delivered and queued in unconsumed messages 3. Listener is added 4. Messages are Redispatched 5. Messages are considered duplicates -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQNET-461) FailoverTransport PoisonAcks Rollbacked messages
Remo Gloor created AMQNET-461: - Summary: FailoverTransport PoisonAcks Rollbacked messages Key: AMQNET-461 URL: https://issues.apache.org/jira/browse/AMQNET-461 Project: ActiveMQ .Net Issue Type: Bug Affects Versions: 1.6.0 Reporter: Remo Gloor Assignee: Jim Gomes When using FailoverTransport with nonBlockingRedelivery messages get PoisonAcked: 1. Message is rolledback e.g. due to a concurrency exception on the db or any other processing error. 2. Message is sheduled for redelivery e.g. in 30 Sec. 3. Connection is lost before message is redelivered 4. Connection is reestablished before message is redelivered. 5. Server redelivers message due to the connection loss 6. Message is dsipatched and processed. 7. Resheduled Message gets dispatched => Duplicate 8. No previously delivered messages => Send PoisonAck => Message is in the DLQ even though it is processed succesfully. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQNET-460) WaitForRedeliveries ignores failoverRedeliveryWaitPeriod
Remo Gloor created AMQNET-460: - Summary: WaitForRedeliveries ignores failoverRedeliveryWaitPeriod Key: AMQNET-460 URL: https://issues.apache.org/jira/browse/AMQNET-460 Project: ActiveMQ .Net Issue Type: Bug Affects Versions: 1.6.0 Reporter: Remo Gloor Assignee: Jim Gomes MessageConsumer.WaitForRedeliveries() while (numberNotReplayed > 0 && expiry < DateTime.Now); should be while (numberNotReplayed > 0 && expiry > DateTime.Now); -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQ-4882) LevelDB can get to a corrupt state
[ https://issues.apache.org/jira/browse/AMQ-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQ-4882: Attachment: TestClient.zip > LevelDB can get to a corrupt state > -- > > Key: AMQ-4882 > URL: https://issues.apache.org/jira/browse/AMQ-4882 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-leveldb-store >Affects Versions: 5.9.0 >Reporter: Remo Gloor >Priority: Critical > Attachments: TestClient.zip, activemq.log > > > A consumer/producer with failover transport is connected to AMQ and processes > messages in XA Transactions. When AMQ is restarted is can happen that LevelDB > gets to a corrupt state so that AMQ can not be started anymore without > deletind the database. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQ-4882) LevelDB can get to a corrupt state
[ https://issues.apache.org/jira/browse/AMQ-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQ-4882: Description: A consumer/producer with failover transport is connected to AMQ and processes messages in XA Transactions. When AMQ is restarted is can happen that LevelDB gets to a corrupt state so that AMQ can not be started anymore without deletind the database. Reproduction: - Configure AMQ with LevelDB - Run the attached TestClient - Restart AMQ several times. At some time it won't start anymore and produced the exception in the attached log file. was:A consumer/producer with failover transport is connected to AMQ and processes messages in XA Transactions. When AMQ is restarted is can happen that LevelDB gets to a corrupt state so that AMQ can not be started anymore without deletind the database. > LevelDB can get to a corrupt state > -- > > Key: AMQ-4882 > URL: https://issues.apache.org/jira/browse/AMQ-4882 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-leveldb-store >Affects Versions: 5.9.0 >Reporter: Remo Gloor >Priority: Critical > Attachments: TestClient.zip, activemq.log > > > A consumer/producer with failover transport is connected to AMQ and processes > messages in XA Transactions. When AMQ is restarted is can happen that LevelDB > gets to a corrupt state so that AMQ can not be started anymore without > deletind the database. > Reproduction: > - Configure AMQ with LevelDB > - Run the attached TestClient > - Restart AMQ several times. At some time it won't start anymore and produced > the exception in the attached log file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQ-4882) LevelDB can get to a corrupt state
[ https://issues.apache.org/jira/browse/AMQ-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQ-4882: Attachment: activemq.log > LevelDB can get to a corrupt state > -- > > Key: AMQ-4882 > URL: https://issues.apache.org/jira/browse/AMQ-4882 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-leveldb-store >Affects Versions: 5.9.0 >Reporter: Remo Gloor >Priority: Critical > Attachments: activemq.log > > > A consumer/producer with failover transport is connected to AMQ and processes > messages in XA Transactions. When AMQ is restarted is can happen that LevelDB > gets to a corrupt state so that AMQ can not be started anymore without > deletind the database. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQ-4882) LevelDB can get to a corrupt state
Remo Gloor created AMQ-4882: --- Summary: LevelDB can get to a corrupt state Key: AMQ-4882 URL: https://issues.apache.org/jira/browse/AMQ-4882 Project: ActiveMQ Issue Type: Bug Components: activemq-leveldb-store Affects Versions: 5.9.0 Reporter: Remo Gloor Priority: Critical A consumer/producer with failover transport is connected to AMQ and processes messages in XA Transactions. When AMQ is restarted is can happen that LevelDB gets to a corrupt state so that AMQ can not be started anymore without deletind the database. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQ-4878) Message can be acknowledged succesfully it two different transactions
[ https://issues.apache.org/jira/browse/AMQ-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQ-4878: Affects Version/s: 5.9.0 > Message can be acknowledged succesfully it two different transactions > - > > Key: AMQ-4878 > URL: https://issues.apache.org/jira/browse/AMQ-4878 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.9.0 >Reporter: Remo Gloor > > - Two clients are connected to AMQ listening on the same queue. > - When a message is sent to that queue it is processed and acknowledged by > one of these clients in a transaction. After processing it does a 2 phase > commit. > - The connection is lost right after prepare is sent. The failover now > reconnects and replays these messages and sends a commit later. > - After the connection is lost AMQ sends the same message to the other client > due to the connection loss (most likely because the prepare did not arrive). > This client creates another transaction, processes and acknowledges the > message. The transaction is now prepared and commit. > The problem is that the same message is processed in two clients succesfully. > Both were able to acknowledge the message in two different transactions. I'd > expect that just one (the first?) prepare that arrives at the server is > succesful. The other must fail so that all the work done on that client (e.g. > DB modifications and sent messages) is reverted by this second transaction. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQ-4878) Message can be acknowledged succesfully it two different transactions
Remo Gloor created AMQ-4878: --- Summary: Message can be acknowledged succesfully it two different transactions Key: AMQ-4878 URL: https://issues.apache.org/jira/browse/AMQ-4878 Project: ActiveMQ Issue Type: Bug Reporter: Remo Gloor - Two clients are connected to AMQ listening on the same queue. - When a message is sent to that queue it is processed and acknowledged by one of these clients in a transaction. After processing it does a 2 phase commit. - The connection is lost right after prepare is sent. The failover now reconnects and replays these messages and sends a commit later. - After the connection is lost AMQ sends the same message to the other client due to the connection loss (most likely because the prepare did not arrive). This client creates another transaction, processes and acknowledges the message. The transaction is now prepared and commit. The problem is that the same message is processed in two clients succesfully. Both were able to acknowledge the message in two different transactions. I'd expect that just one (the first?) prepare that arrives at the server is succesful. The other must fail so that all the work done on that client (e.g. DB modifications and sent messages) is reverted by this second transaction. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQNET-413) Message producers do not respect DTC Transactions correctly
[
https://issues.apache.org/jira/browse/AMQNET-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815433#comment-13815433
]
Remo Gloor commented on AMQNET-413:
---
I can understand that you don't fix this for 1.6.x. But what is the problem to
apply that on the trunk?
> Message producers do not respect DTC Transactions correctly
> ---
>
> Key: AMQNET-413
> URL: https://issues.apache.org/jira/browse/AMQNET-413
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ
>Reporter: Remo Gloor
>Assignee: Jim Gomes
> Attachments: AMQNET-413.patch,
> AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
> AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
> allDTCImprovments.patch
>
>
> When consuming messages in a transaction and sending new ones during
> processing of that message and the transaction is rolled back and commited on
> retry the number of published messages should be equal to the received one.
> But the number of sent message is bigger than the number of received ones.
> This means some of the message sends are not rolled back others are.
> EDIT: Further analysis have shown that the TransactionContext.TransactionId
> is null when sending eventhough a transaction is in progress and not yet
> completed. It must incorrectly be assigned to null somewhere.
> The following application demonstrates the problem when enqueuing 100+
> messages to foo.bar
> class Program
> {
> private static INetTxSession activeMqSession;
> private static IMessageConsumer consumer;
> private static INetTxConnection connection;
> static void Main(string[] args)
> {
> using (connection = CreateActiveMqConnection())
> using (activeMqSession = connection.CreateNetTxSession())
> using (consumer =
> activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
> "queue://foo.bar")))
> {
> connection.Start();
> while (true)
> {
> try
> {
> using (TransactionScope scoped = new
> TransactionScope(TransactionScopeOption.RequiresNew))
> {
> IMessage msg = null;
> while (msg == null)
> {
> msg = consumer.ReceiveNoWait();
> }
> OnMessage(msg);
> scoped.Complete();
> }
> }
> catch(Exception exception) {}
> }
> }
> }
> private static INetTxConnection CreateActiveMqConnection()
> {
> var connectionFactory = new
> Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
> {
> AcknowledgementMode = AcknowledgementMode.Transactional
> };
> return connectionFactory.CreateNetTxConnection();
> }
> private static void OnMessage(IMessage message)
> {
> var x = new TestSinglePhaseCommit();
> Console.WriteLine("Processing message {0} in transaction {1} -
> {2}", message.NMSMessageId,
> Transaction.Current.TransactionInformation.LocalIdentifier,
> Transaction.Current.TransactionInformation.DistributedIdentifier);
> var session2 = activeMqSession;
> {
> Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
> EnlistmentOptions.None);
> using (var producer =
> session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
> {
> producer.Send(new ActiveMQTextMessage("foo"));
> }
> if (!message.NMSRedelivered) throw new Exception();
> }
> }
> }
> internal class TestSinglePhaseCommit : ISinglePhaseNotification
> {
> public void Prepare(PreparingEnlistment preparingEnlistment)
> {
> preparingEnlistment.Prepared();
> }
> public void Commit(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void Rollback(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void InDoubt(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void SinglePhaseCommit(SinglePhaseEnlistment
> singlePhaseEnlistment)
> {
> singlePhaseEnlistment.Committed();
> }
> }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (AMQNET-413) Message producers do not respect DTC Transactions correctly
[
https://issues.apache.org/jira/browse/AMQNET-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815416#comment-13815416
]
Remo Gloor commented on AMQNET-413:
---
I can compile that code against .NET 2.0 in VS 2012/2013. Probably you are
using an old compiler.
> Message producers do not respect DTC Transactions correctly
> ---
>
> Key: AMQNET-413
> URL: https://issues.apache.org/jira/browse/AMQNET-413
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ
>Reporter: Remo Gloor
>Assignee: Jim Gomes
> Attachments: AMQNET-413.patch,
> AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
> AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
> allDTCImprovments.patch
>
>
> When consuming messages in a transaction and sending new ones during
> processing of that message and the transaction is rolled back and commited on
> retry the number of published messages should be equal to the received one.
> But the number of sent message is bigger than the number of received ones.
> This means some of the message sends are not rolled back others are.
> EDIT: Further analysis have shown that the TransactionContext.TransactionId
> is null when sending eventhough a transaction is in progress and not yet
> completed. It must incorrectly be assigned to null somewhere.
> The following application demonstrates the problem when enqueuing 100+
> messages to foo.bar
> class Program
> {
> private static INetTxSession activeMqSession;
> private static IMessageConsumer consumer;
> private static INetTxConnection connection;
> static void Main(string[] args)
> {
> using (connection = CreateActiveMqConnection())
> using (activeMqSession = connection.CreateNetTxSession())
> using (consumer =
> activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
> "queue://foo.bar")))
> {
> connection.Start();
> while (true)
> {
> try
> {
> using (TransactionScope scoped = new
> TransactionScope(TransactionScopeOption.RequiresNew))
> {
> IMessage msg = null;
> while (msg == null)
> {
> msg = consumer.ReceiveNoWait();
> }
> OnMessage(msg);
> scoped.Complete();
> }
> }
> catch(Exception exception) {}
> }
> }
> }
> private static INetTxConnection CreateActiveMqConnection()
> {
> var connectionFactory = new
> Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
> {
> AcknowledgementMode = AcknowledgementMode.Transactional
> };
> return connectionFactory.CreateNetTxConnection();
> }
> private static void OnMessage(IMessage message)
> {
> var x = new TestSinglePhaseCommit();
> Console.WriteLine("Processing message {0} in transaction {1} -
> {2}", message.NMSMessageId,
> Transaction.Current.TransactionInformation.LocalIdentifier,
> Transaction.Current.TransactionInformation.DistributedIdentifier);
> var session2 = activeMqSession;
> {
> Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
> EnlistmentOptions.None);
> using (var producer =
> session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
> {
> producer.Send(new ActiveMQTextMessage("foo"));
> }
> if (!message.NMSRedelivered) throw new Exception();
> }
> }
> }
> internal class TestSinglePhaseCommit : ISinglePhaseNotification
> {
> public void Prepare(PreparingEnlistment preparingEnlistment)
> {
> preparingEnlistment.Prepared();
> }
> public void Commit(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void Rollback(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void InDoubt(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void SinglePhaseCommit(SinglePhaseEnlistment
> singlePhaseEnlistment)
> {
> singlePhaseEnlistment.Committed();
> }
> }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (AMQNET-422) Added support for transactions for Asyncronous Listeners
[
https://issues.apache.org/jira/browse/AMQNET-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815413#comment-13815413
]
Remo Gloor commented on AMQNET-422:
---
I can compile that code to .NET 2.0 at least in VS 2012 and 2013. Are you using
an old compiler?
And the only change to None DTC that some code was extracted from Dispatch into
a new method DispatchToAsyncListener. Is this really a too big change?
> Added support for transactions for Asyncronous Listeners
>
>
> Key: AMQNET-422
> URL: https://issues.apache.org/jira/browse/AMQNET-422
> Project: ActiveMQ .Net
> Issue Type: New Feature
> Components: ActiveMQ
>Reporter: Remo Gloor
>Assignee: Jim Gomes
>Priority: Minor
> Attachments: AddedSupportForAmbientTransactionForAsyncConsumers -
> When_AMQNET-413_IsFixed.patch,
> AddedSupportForAmbientTransactionForAsyncConsumers.patch,
> AddedSupportForAmbientTransactionForAsyncConsumers.patch,
> allDTCImprovments.patch
>
>
> Asyncronous Listeners do not support transactions properly. I suggest to add
> the option to register a callback that can be used to create a transaction
> for each message received by the asyncronous listener.
> e.g.
> ((MessageConsumer)consumer).CreateTransactionScopeForAsyncMessage =
> this.CreateScope;
> private TransactionScope CreateScope()
> {
> return new TransactionScope(TransactionScopeOption.RequiresNew);
> }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (AMQNET-422) Added support for transactions for Asyncronous Listeners
[
https://issues.apache.org/jira/browse/AMQNET-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remo Gloor updated AMQNET-422:
--
Attachment: AddedSupportForAmbientTransactionForAsyncConsumers.patch
AddedSupportForAmbientTransactionForAsyncConsumers -
When_AMQNET-413_IsFixed.patch
Updated for 1.6.1
> Added support for transactions for Asyncronous Listeners
>
>
> Key: AMQNET-422
> URL: https://issues.apache.org/jira/browse/AMQNET-422
> Project: ActiveMQ .Net
> Issue Type: New Feature
> Components: ActiveMQ
>Reporter: Remo Gloor
>Assignee: Jim Gomes
>Priority: Minor
> Attachments: AddedSupportForAmbientTransactionForAsyncConsumers -
> When_AMQNET-413_IsFixed.patch,
> AddedSupportForAmbientTransactionForAsyncConsumers.patch,
> AddedSupportForAmbientTransactionForAsyncConsumers.patch,
> allDTCImprovments.patch
>
>
> Asyncronous Listeners do not support transactions properly. I suggest to add
> the option to register a callback that can be used to create a transaction
> for each message received by the asyncronous listener.
> e.g.
> ((MessageConsumer)consumer).CreateTransactionScopeForAsyncMessage =
> this.CreateScope;
> private TransactionScope CreateScope()
> {
> return new TransactionScope(TransactionScopeOption.RequiresNew);
> }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (AMQNET-413) Message producers do not respect DTC Transactions correctly
[
https://issues.apache.org/jira/browse/AMQNET-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814693#comment-13814693
]
Remo Gloor commented on AMQNET-413:
---
Is there any intent to integrate the open patches or fix the related issues in
any other way?
I'm asking because we detected several issues with the newly added failover
transport redelivery code. Fixing those for any possible acknowledge mode and
Listener/NoListener combination will be much more work than just fixing our own
case. If we have to maintain our own version anyway because the open patches
are not applied then there is little reason to do this additional work to get
it fixed for all situations.
> Message producers do not respect DTC Transactions correctly
> ---
>
> Key: AMQNET-413
> URL: https://issues.apache.org/jira/browse/AMQNET-413
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ
>Reporter: Remo Gloor
>Assignee: Jim Gomes
> Attachments: AMQNET-413.patch,
> AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
> AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
> allDTCImprovments.patch
>
>
> When consuming messages in a transaction and sending new ones during
> processing of that message and the transaction is rolled back and commited on
> retry the number of published messages should be equal to the received one.
> But the number of sent message is bigger than the number of received ones.
> This means some of the message sends are not rolled back others are.
> EDIT: Further analysis have shown that the TransactionContext.TransactionId
> is null when sending eventhough a transaction is in progress and not yet
> completed. It must incorrectly be assigned to null somewhere.
> The following application demonstrates the problem when enqueuing 100+
> messages to foo.bar
> class Program
> {
> private static INetTxSession activeMqSession;
> private static IMessageConsumer consumer;
> private static INetTxConnection connection;
> static void Main(string[] args)
> {
> using (connection = CreateActiveMqConnection())
> using (activeMqSession = connection.CreateNetTxSession())
> using (consumer =
> activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
> "queue://foo.bar")))
> {
> connection.Start();
> while (true)
> {
> try
> {
> using (TransactionScope scoped = new
> TransactionScope(TransactionScopeOption.RequiresNew))
> {
> IMessage msg = null;
> while (msg == null)
> {
> msg = consumer.ReceiveNoWait();
> }
> OnMessage(msg);
> scoped.Complete();
> }
> }
> catch(Exception exception) {}
> }
> }
> }
> private static INetTxConnection CreateActiveMqConnection()
> {
> var connectionFactory = new
> Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
> {
> AcknowledgementMode = AcknowledgementMode.Transactional
> };
> return connectionFactory.CreateNetTxConnection();
> }
> private static void OnMessage(IMessage message)
> {
> var x = new TestSinglePhaseCommit();
> Console.WriteLine("Processing message {0} in transaction {1} -
> {2}", message.NMSMessageId,
> Transaction.Current.TransactionInformation.LocalIdentifier,
> Transaction.Current.TransactionInformation.DistributedIdentifier);
> var session2 = activeMqSession;
> {
> Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
> EnlistmentOptions.None);
> using (var producer =
> session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
> {
> producer.Send(new ActiveMQTextMessage("foo"));
> }
> if (!message.NMSRedelivered) throw new Exception();
> }
> }
> }
> internal class TestSinglePhaseCommit : ISinglePhaseNotification
> {
> public void Prepare(PreparingEnlistment preparingEnlistment)
> {
> preparingEnlistment.Prepared();
> }
> public void Commit(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void Rollback(Enlistment enlistment)
>
[jira] [Updated] (AMQNET-417) DTC Recovery should be done once for each application start
[ https://issues.apache.org/jira/browse/AMQNET-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-417: -- Priority: Major (was: Minor) > DTC Recovery should be done once for each application start > --- > > Key: AMQNET-417 > URL: https://issues.apache.org/jira/browse/AMQNET-417 > Project: ActiveMQ .Net > Issue Type: Bug > Components: ActiveMQ >Reporter: Remo Gloor >Assignee: Jim Gomes > Attachments: allDTCImprovments.patch, > DtcRecoveryShouldNotRunAfterConnectionsAreStarted.patch, > DtcRecoveryShouldNotRunAfterConnectionsAreStarted.patch > > > DTC recovery is currently executed when a new session is created. This is not > correct because there can be other sessions that are currently commiting a > transaction. This transactions must not be recovered, otherwise there are > strange behaviors. > The recovery should be done just once foreach ressource manager ID. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQNET-417) DTC Recovery should be done once for each application start
[ https://issues.apache.org/jira/browse/AMQNET-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-417: -- Issue Type: Bug (was: New Feature) > DTC Recovery should be done once for each application start > --- > > Key: AMQNET-417 > URL: https://issues.apache.org/jira/browse/AMQNET-417 > Project: ActiveMQ .Net > Issue Type: Bug > Components: ActiveMQ >Reporter: Remo Gloor >Assignee: Jim Gomes >Priority: Minor > Attachments: allDTCImprovments.patch, > DtcRecoveryShouldNotRunAfterConnectionsAreStarted.patch, > DtcRecoveryShouldNotRunAfterConnectionsAreStarted.patch > > > DTC recovery is currently executed when a new session is created. This is not > correct because there can be other sessions that are currently commiting a > transaction. This transactions must not be recovered, otherwise there are > strange behaviors. > The recovery should be done just once foreach ressource manager ID. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQNET-417) DTC Recovery should be done once for each application start
[ https://issues.apache.org/jira/browse/AMQNET-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-417: -- Attachment: DtcRecoveryShouldNotRunAfterConnectionsAreStarted.patch Updated Patch to 1.6.1 > DTC Recovery should be done once for each application start > --- > > Key: AMQNET-417 > URL: https://issues.apache.org/jira/browse/AMQNET-417 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: ActiveMQ >Reporter: Remo Gloor >Assignee: Jim Gomes >Priority: Minor > Attachments: allDTCImprovments.patch, > DtcRecoveryShouldNotRunAfterConnectionsAreStarted.patch, > DtcRecoveryShouldNotRunAfterConnectionsAreStarted.patch > > > DTC recovery is currently executed when a new session is created. This is not > correct because there can be other sessions that are currently commiting a > transaction. This transactions must not be recovered, otherwise there are > strange behaviors. > The recovery should be done just once foreach ressource manager ID. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQNET-418) Recovery File Logger does not support multiple concurrent transactions
[ https://issues.apache.org/jira/browse/AMQNET-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-418: -- Issue Type: Bug (was: New Feature) > Recovery File Logger does not support multiple concurrent transactions > -- > > Key: AMQNET-418 > URL: https://issues.apache.org/jira/browse/AMQNET-418 > Project: ActiveMQ .Net > Issue Type: Bug > Components: ActiveMQ >Reporter: Remo Gloor >Assignee: Jim Gomes >Priority: Minor > Attachments: allDTCImprovments.patch, > RecoveryLoggerDoesNotSupportMultipleTransactions.patch, > RecoveryLoggerDoesNotSupportMultipleTransactions.patch > > > Currently it is not possible to use more than one session if you use DTC > Transactions. This is because the RecoveryFileLogger can not handle more than > one transaction simultanously. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQNET-418) Recovery File Logger does not support multiple concurrent transactions
[ https://issues.apache.org/jira/browse/AMQNET-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-418: -- Priority: Major (was: Minor) > Recovery File Logger does not support multiple concurrent transactions > -- > > Key: AMQNET-418 > URL: https://issues.apache.org/jira/browse/AMQNET-418 > Project: ActiveMQ .Net > Issue Type: Bug > Components: ActiveMQ >Reporter: Remo Gloor >Assignee: Jim Gomes > Attachments: allDTCImprovments.patch, > RecoveryLoggerDoesNotSupportMultipleTransactions.patch, > RecoveryLoggerDoesNotSupportMultipleTransactions.patch > > > Currently it is not possible to use more than one session if you use DTC > Transactions. This is because the RecoveryFileLogger can not handle more than > one transaction simultanously. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQNET-418) Recovery File Logger does not support multiple concurrent transactions
[ https://issues.apache.org/jira/browse/AMQNET-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-418: -- Attachment: RecoveryLoggerDoesNotSupportMultipleTransactions.patch Updated Patch to 1.6.1 > Recovery File Logger does not support multiple concurrent transactions > -- > > Key: AMQNET-418 > URL: https://issues.apache.org/jira/browse/AMQNET-418 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: ActiveMQ >Reporter: Remo Gloor >Assignee: Jim Gomes >Priority: Minor > Attachments: allDTCImprovments.patch, > RecoveryLoggerDoesNotSupportMultipleTransactions.patch, > RecoveryLoggerDoesNotSupportMultipleTransactions.patch > > > Currently it is not possible to use more than one session if you use DTC > Transactions. This is because the RecoveryFileLogger can not handle more than > one transaction simultanously. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQNET-413) Message producers do not respect DTC Transactions correctly
[
https://issues.apache.org/jira/browse/AMQNET-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remo Gloor updated AMQNET-413:
--
Attachment:
AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch
Updated Patch for 1.6.1
> Message producers do not respect DTC Transactions correctly
> ---
>
> Key: AMQNET-413
> URL: https://issues.apache.org/jira/browse/AMQNET-413
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ
>Reporter: Remo Gloor
>Assignee: Jim Gomes
> Attachments: allDTCImprovments.patch,
> AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
> AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
> AMQNET-413.patch
>
>
> When consuming messages in a transaction and sending new ones during
> processing of that message and the transaction is rolled back and commited on
> retry the number of published messages should be equal to the received one.
> But the number of sent message is bigger than the number of received ones.
> This means some of the message sends are not rolled back others are.
> EDIT: Further analysis have shown that the TransactionContext.TransactionId
> is null when sending eventhough a transaction is in progress and not yet
> completed. It must incorrectly be assigned to null somewhere.
> The following application demonstrates the problem when enqueuing 100+
> messages to foo.bar
> class Program
> {
> private static INetTxSession activeMqSession;
> private static IMessageConsumer consumer;
> private static INetTxConnection connection;
> static void Main(string[] args)
> {
> using (connection = CreateActiveMqConnection())
> using (activeMqSession = connection.CreateNetTxSession())
> using (consumer =
> activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
> "queue://foo.bar")))
> {
> connection.Start();
> while (true)
> {
> try
> {
> using (TransactionScope scoped = new
> TransactionScope(TransactionScopeOption.RequiresNew))
> {
> IMessage msg = null;
> while (msg == null)
> {
> msg = consumer.ReceiveNoWait();
> }
> OnMessage(msg);
> scoped.Complete();
> }
> }
> catch(Exception exception) {}
> }
> }
> }
> private static INetTxConnection CreateActiveMqConnection()
> {
> var connectionFactory = new
> Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
> {
> AcknowledgementMode = AcknowledgementMode.Transactional
> };
> return connectionFactory.CreateNetTxConnection();
> }
> private static void OnMessage(IMessage message)
> {
> var x = new TestSinglePhaseCommit();
> Console.WriteLine("Processing message {0} in transaction {1} -
> {2}", message.NMSMessageId,
> Transaction.Current.TransactionInformation.LocalIdentifier,
> Transaction.Current.TransactionInformation.DistributedIdentifier);
> var session2 = activeMqSession;
> {
> Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
> EnlistmentOptions.None);
> using (var producer =
> session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
> {
> producer.Send(new ActiveMQTextMessage("foo"));
> }
> if (!message.NMSRedelivered) throw new Exception();
> }
> }
> }
> internal class TestSinglePhaseCommit : ISinglePhaseNotification
> {
> public void Prepare(PreparingEnlistment preparingEnlistment)
> {
> preparingEnlistment.Prepared();
> }
> public void Commit(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void Rollback(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void InDoubt(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void SinglePhaseCommit(SinglePhaseEnlistment
> singlePhaseEnlistment)
> {
> singlePhaseEnlistment.Committed();
> }
> }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (AMQNET-456) Format Exception in TransportFactory
[ https://issues.apache.org/jira/browse/AMQNET-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-456: -- Affects Version/s: 1.6.0 > Format Exception in TransportFactory > > > Key: AMQNET-456 > URL: https://issues.apache.org/jira/browse/AMQNET-456 > Project: ActiveMQ .Net > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Remo Gloor >Assignee: Jim Gomes >Priority: Minor > Attachments: TransportFactory.cs.patch > > > TransportFactory can throw a format exception -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQNET-456) Format Exception in TransportFactory
[ https://issues.apache.org/jira/browse/AMQNET-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-456: -- Attachment: TransportFactory.cs.patch > Format Exception in TransportFactory > > > Key: AMQNET-456 > URL: https://issues.apache.org/jira/browse/AMQNET-456 > Project: ActiveMQ .Net > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Remo Gloor >Assignee: Jim Gomes >Priority: Minor > Attachments: TransportFactory.cs.patch > > > TransportFactory can throw a format exception -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQNET-456) Format Exception in TransportFactory
Remo Gloor created AMQNET-456: - Summary: Format Exception in TransportFactory Key: AMQNET-456 URL: https://issues.apache.org/jira/browse/AMQNET-456 Project: ActiveMQ .Net Issue Type: Bug Reporter: Remo Gloor Assignee: Jim Gomes Priority: Minor Attachments: TransportFactory.cs.patch TransportFactory can throw a format exception -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Reopened] (AMQNET-450) NetTxTransaction replay is incorrect when using Failover Transport
[ https://issues.apache.org/jira/browse/AMQNET-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor reopened AMQNET-450: --- The following methods reuse commands too and need to clone them: NetTxTransactionContext.Rollback NetTxTransactionContext.InDoubt > NetTxTransaction replay is incorrect when using Failover Transport > -- > > Key: AMQNET-450 > URL: https://issues.apache.org/jira/browse/AMQNET-450 > Project: ActiveMQ .Net > Issue Type: Bug > Components: ActiveMQ, NMS >Affects Versions: 1.6.0 >Reporter: Remo Gloor >Assignee: Timothy Bish > Fix For: 1.6.1 > > Attachments: TransactionState.cs.patch > > > TransactionState.AddCommand must clone the operation because TransactionInfo > command instances are reused (e.g. in NetTxTransactionContext.Prepare()). > If they are not cloned then the list will contain the second command twice > and the no instance of the first command because the first command is changed > after added to the list by the reassignment of some values when it is reused. > This results in wrong replied messages on reconnects. > Another solution is not to reuse any command instance in the whole code. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQNET-451) ConnectionStateTracker.TraceBack is obsolete code
Remo Gloor created AMQNET-451: - Summary: ConnectionStateTracker.TraceBack is obsolete code Key: AMQNET-451 URL: https://issues.apache.org/jira/browse/AMQNET-451 Project: ActiveMQ .Net Issue Type: Improvement Affects Versions: 1.6.0 Reporter: Remo Gloor Assignee: Jim Gomes Priority: Trivial ConnectionStateTracker.TraceBack() does not do anything but increment an unused internal variable. Remove obsolete code. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQNET-450) NetTxTransaction replay is incorrect when using Failover Transport
[ https://issues.apache.org/jira/browse/AMQNET-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-450: -- Attachment: TransactionState.cs.patch > NetTxTransaction replay is incorrect when using Failover Transport > -- > > Key: AMQNET-450 > URL: https://issues.apache.org/jira/browse/AMQNET-450 > Project: ActiveMQ .Net > Issue Type: Bug > Components: ActiveMQ, NMS >Affects Versions: 1.6.0 >Reporter: Remo Gloor >Assignee: Jim Gomes > Fix For: 1.6.1 > > Attachments: TransactionState.cs.patch > > > TransactionState.AddCommand must clone the operation because TransactionInfo > command instances are reused (e.g. in NetTxTransactionContext.Prepare()). > If they are not cloned then the list will contain the second command twice > and the no instance of the first command because the first command is changed > after added to the list by the reassignment of some values when it is reused. > This results in wrong replied messages on reconnects. > Another solution is not to reuse any command instance in the whole code. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQNET-450) NetTxTransaction replay is incorrect when using Failover Transport
[ https://issues.apache.org/jira/browse/AMQNET-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-450: -- Component/s: NMS ActiveMQ Affects Version/s: 1.6.0 Fix Version/s: 1.6.1 > NetTxTransaction replay is incorrect when using Failover Transport > -- > > Key: AMQNET-450 > URL: https://issues.apache.org/jira/browse/AMQNET-450 > Project: ActiveMQ .Net > Issue Type: Bug > Components: ActiveMQ, NMS >Affects Versions: 1.6.0 >Reporter: Remo Gloor >Assignee: Jim Gomes > Fix For: 1.6.1 > > Attachments: TransactionState.cs.patch > > > TransactionState.AddCommand must clone the operation because TransactionInfo > command instances are reused (e.g. in NetTxTransactionContext.Prepare()). > If they are not cloned then the list will contain the second command twice > and the no instance of the first command because the first command is changed > after added to the list by the reassignment of some values when it is reused. > This results in wrong replied messages on reconnects. > Another solution is not to reuse any command instance in the whole code. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQNET-450) NetTxTransaction replay is incorrect when using Failover Transport
Remo Gloor created AMQNET-450: - Summary: NetTxTransaction replay is incorrect when using Failover Transport Key: AMQNET-450 URL: https://issues.apache.org/jira/browse/AMQNET-450 Project: ActiveMQ .Net Issue Type: Bug Reporter: Remo Gloor Assignee: Jim Gomes TransactionState.AddCommand must clone the operation because TransactionInfo command instances are reused (e.g. in NetTxTransactionContext.Prepare()). If they are not cloned then the list will contain the second command twice and the no instance of the first command because the first command is changed after added to the list by the reassignment of some values when it is reused. This results in wrong replied messages on reconnects. Another solution is not to reuse any command instance in the whole code. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (AMQNET-443) Better logging for XATransaction
[ https://issues.apache.org/jira/browse/AMQNET-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-443: -- Affects Version/s: 1.6.0 > Better logging for XATransaction > > > Key: AMQNET-443 > URL: https://issues.apache.org/jira/browse/AMQNET-443 > Project: ActiveMQ .Net > Issue Type: Improvement >Affects Versions: 1.6.0 >Reporter: Remo Gloor >Assignee: Jim Gomes >Priority: Minor > Attachments: BetterLoggingForXATransaction.patch > > > The current log output is not really helpful because you don't see what for > which transaction the log entry is written: > DEBUG: Transaction Rollback Done TX id: XATransactionId[ FormatId = 0, > GlobalTransactionId = System.Byte[] > The patch will change this to: > DEBUG: Transaction Rollback Done TX id: XATransactionId[ FormatId = 0, > GlobalTransactionId = DF0D6FAA45EAA44885A322CD299493AD, BranchQualifier = > c23f8230-9892-49c7-a3ed-6e6bd5ffd05c ] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQNET-443) Better logging for XATransaction
[ https://issues.apache.org/jira/browse/AMQNET-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-443: -- Attachment: BetterLoggingForXATransaction.patch > Better logging for XATransaction > > > Key: AMQNET-443 > URL: https://issues.apache.org/jira/browse/AMQNET-443 > Project: ActiveMQ .Net > Issue Type: Improvement >Reporter: Remo Gloor >Assignee: Jim Gomes >Priority: Minor > Attachments: BetterLoggingForXATransaction.patch > > > The current log output is not really helpful because you don't see what for > which transaction the log entry is written: > DEBUG: Transaction Rollback Done TX id: XATransactionId[ FormatId = 0, > GlobalTransactionId = System.Byte[] > The patch will change this to: > DEBUG: Transaction Rollback Done TX id: XATransactionId[ FormatId = 0, > GlobalTransactionId = DF0D6FAA45EAA44885A322CD299493AD, BranchQualifier = > c23f8230-9892-49c7-a3ed-6e6bd5ffd05c ] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQNET-443) Better logging for XATransaction
Remo Gloor created AMQNET-443: - Summary: Better logging for XATransaction Key: AMQNET-443 URL: https://issues.apache.org/jira/browse/AMQNET-443 Project: ActiveMQ .Net Issue Type: Improvement Reporter: Remo Gloor Assignee: Jim Gomes Priority: Minor The current log output is not really helpful because you don't see what for which transaction the log entry is written: DEBUG: Transaction Rollback Done TX id: XATransactionId[ FormatId = 0, GlobalTransactionId = System.Byte[] The patch will change this to: DEBUG: Transaction Rollback Done TX id: XATransactionId[ FormatId = 0, GlobalTransactionId = DF0D6FAA45EAA44885A322CD299493AD, BranchQualifier = c23f8230-9892-49c7-a3ed-6e6bd5ffd05c ] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQNET-418) Recovery File Logger does not support multiple concurrent transactions
[ https://issues.apache.org/jira/browse/AMQNET-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13666147#comment-13666147 ] Remo Gloor commented on AMQNET-418: --- No it isn't. It seems that topic isn't taken very serious. We are currently running a custom build with the allDTCImprovments.patch (https://github.com/NServiceBus/NServiceBus/tree/develop/lib/Apache.NMS-CustomBuild). Without that DTC support is broken. > Recovery File Logger does not support multiple concurrent transactions > -- > > Key: AMQNET-418 > URL: https://issues.apache.org/jira/browse/AMQNET-418 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: ActiveMQ >Reporter: Remo Gloor >Assignee: Jim Gomes >Priority: Minor > Attachments: allDTCImprovments.patch, > RecoveryLoggerDoesNotSupportMultipleTransactions.patch > > > Currently it is not possible to use more than one session if you use DTC > Transactions. This is because the RecoveryFileLogger can not handle more than > one transaction simultanously. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQNET-417) DTC Recovery should be done once for each application start
[ https://issues.apache.org/jira/browse/AMQNET-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662820#comment-13662820 ] Remo Gloor commented on AMQNET-417: --- This is neither a new feature nor minor. All applications using DTC and more than one session won't run properly. > DTC Recovery should be done once for each application start > --- > > Key: AMQNET-417 > URL: https://issues.apache.org/jira/browse/AMQNET-417 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: ActiveMQ >Reporter: Remo Gloor >Assignee: Jim Gomes >Priority: Minor > Attachments: allDTCImprovments.patch, > DtcRecoveryShouldNotRunAfterConnectionsAreStarted.patch > > > DTC recovery is currently executed when a new session is created. This is not > correct because there can be other sessions that are currently commiting a > transaction. This transactions must not be recovered, otherwise there are > strange behaviors. > The recovery should be done just once foreach ressource manager ID. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (AMQNET-413) Message producers do not respect DTC Transactions correctly
[
https://issues.apache.org/jira/browse/AMQNET-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remo Gloor reopened AMQNET-413:
---
Not fixed
> Message producers do not respect DTC Transactions correctly
> ---
>
> Key: AMQNET-413
> URL: https://issues.apache.org/jira/browse/AMQNET-413
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ
>Reporter: Remo Gloor
>Assignee: Jim Gomes
> Attachments: allDTCImprovments.patch,
> AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
> AMQNET-413.patch
>
>
> When consuming messages in a transaction and sending new ones during
> processing of that message and the transaction is rolled back and commited on
> retry the number of published messages should be equal to the received one.
> But the number of sent message is bigger than the number of received ones.
> This means some of the message sends are not rolled back others are.
> EDIT: Further analysis have shown that the TransactionContext.TransactionId
> is null when sending eventhough a transaction is in progress and not yet
> completed. It must incorrectly be assigned to null somewhere.
> The following application demonstrates the problem when enqueuing 100+
> messages to foo.bar
> class Program
> {
> private static INetTxSession activeMqSession;
> private static IMessageConsumer consumer;
> private static INetTxConnection connection;
> static void Main(string[] args)
> {
> using (connection = CreateActiveMqConnection())
> using (activeMqSession = connection.CreateNetTxSession())
> using (consumer =
> activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
> "queue://foo.bar")))
> {
> connection.Start();
> while (true)
> {
> try
> {
> using (TransactionScope scoped = new
> TransactionScope(TransactionScopeOption.RequiresNew))
> {
> IMessage msg = null;
> while (msg == null)
> {
> msg = consumer.ReceiveNoWait();
> }
> OnMessage(msg);
> scoped.Complete();
> }
> }
> catch(Exception exception) {}
> }
> }
> }
> private static INetTxConnection CreateActiveMqConnection()
> {
> var connectionFactory = new
> Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
> {
> AcknowledgementMode = AcknowledgementMode.Transactional
> };
> return connectionFactory.CreateNetTxConnection();
> }
> private static void OnMessage(IMessage message)
> {
> var x = new TestSinglePhaseCommit();
> Console.WriteLine("Processing message {0} in transaction {1} -
> {2}", message.NMSMessageId,
> Transaction.Current.TransactionInformation.LocalIdentifier,
> Transaction.Current.TransactionInformation.DistributedIdentifier);
> var session2 = activeMqSession;
> {
> Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
> EnlistmentOptions.None);
> using (var producer =
> session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
> {
> producer.Send(new ActiveMQTextMessage("foo"));
> }
> if (!message.NMSRedelivered) throw new Exception();
> }
> }
> }
> internal class TestSinglePhaseCommit : ISinglePhaseNotification
> {
> public void Prepare(PreparingEnlistment preparingEnlistment)
> {
> preparingEnlistment.Prepared();
> }
> public void Commit(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void Rollback(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void InDoubt(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void SinglePhaseCommit(SinglePhaseEnlistment
> singlePhaseEnlistment)
> {
> singlePhaseEnlistment.Committed();
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQNET-416) DTC Ressource ManagerID must be confugurable
[ https://issues.apache.org/jira/browse/AMQNET-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13615398#comment-13615398 ] Remo Gloor commented on AMQNET-416: --- Each servce or in case of out scaling each instance of the service must have an unique id. The id must be consistent between restarts. > DTC Ressource ManagerID must be confugurable > > > Key: AMQNET-416 > URL: https://issues.apache.org/jira/browse/AMQNET-416 > Project: ActiveMQ .Net > Issue Type: Bug > Components: ActiveMQ >Reporter: Remo Gloor >Assignee: Jim Gomes >Priority: Critical > Attachments: allDTCImprovments.patch, > MakeResourceManagerIDConfigurable.patch > > > Currently the ressource manager ID for DTC transactions is set to a value > generated from the Broker ID. With this implementation it is not possible to > have more than one process connected to the same broker because in that case > an exception is thrown when the second process tries to enlist to the > transaction. > I suggest to make this ID configurable by the application. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQNET-422) Added support for transactions for Asyncronous Listeners
[
https://issues.apache.org/jira/browse/AMQNET-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remo Gloor updated AMQNET-422:
--
Attachment: allDTCImprovments.patch
AddedSupportForAmbientTransactionForAsyncConsumers.patch
> Added support for transactions for Asyncronous Listeners
>
>
> Key: AMQNET-422
> URL: https://issues.apache.org/jira/browse/AMQNET-422
> Project: ActiveMQ .Net
> Issue Type: New Feature
>Reporter: Remo Gloor
>Assignee: Jim Gomes
> Attachments:
> AddedSupportForAmbientTransactionForAsyncConsumers.patch,
> allDTCImprovments.patch
>
>
> Asyncronous Listeners do not support transactions properly. I suggest to add
> the option to register a callback that can be used to create a transaction
> for each message received by the asyncronous listener.
> e.g.
> ((MessageConsumer)consumer).CreateTransactionScopeForAsyncMessage =
> this.CreateScope;
> private TransactionScope CreateScope()
> {
> return new TransactionScope(TransactionScopeOption.RequiresNew);
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQNET-422) Added support for transactions for Asyncronous Listeners
Remo Gloor created AMQNET-422:
-
Summary: Added support for transactions for Asyncronous Listeners
Key: AMQNET-422
URL: https://issues.apache.org/jira/browse/AMQNET-422
Project: ActiveMQ .Net
Issue Type: New Feature
Reporter: Remo Gloor
Assignee: Jim Gomes
Attachments: AddedSupportForAmbientTransactionForAsyncConsumers.patch,
allDTCImprovments.patch
Asyncronous Listeners do not support transactions properly. I suggest to add
the option to register a callback that can be used to create a transaction for
each message received by the asyncronous listener.
e.g.
((MessageConsumer)consumer).CreateTransactionScopeForAsyncMessage =
this.CreateScope;
private TransactionScope CreateScope()
{
return new TransactionScope(TransactionScopeOption.RequiresNew);
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQNET-421) Replace Mutex by lock
[ https://issues.apache.org/jira/browse/AMQNET-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-421: -- Attachment: UseLockToMakeSureSyncObjectIsReleasedOnExceptions.patch allDTCImprovments.patch > Replace Mutex by lock > - > > Key: AMQNET-421 > URL: https://issues.apache.org/jira/browse/AMQNET-421 > Project: ActiveMQ .Net > Issue Type: Improvement >Reporter: Remo Gloor >Assignee: Jim Gomes > Attachments: allDTCImprovments.patch, > UseLockToMakeSureSyncObjectIsReleasedOnExceptions.patch > > > The Transaction implementation currently uses a Mutex that is not guarded by > try-finally. In case of an exception the Mutex is kept in an aquired state > and will never recover. > By replacing this by lock they the sync object is properly released on an > exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQNET-421) Replace Mutex by lock
Remo Gloor created AMQNET-421: - Summary: Replace Mutex by lock Key: AMQNET-421 URL: https://issues.apache.org/jira/browse/AMQNET-421 Project: ActiveMQ .Net Issue Type: Improvement Reporter: Remo Gloor Assignee: Jim Gomes The Transaction implementation currently uses a Mutex that is not guarded by try-finally. In case of an exception the Mutex is kept in an aquired state and will never recover. By replacing this by lock they the sync object is properly released on an exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQNET-413) Message producers do not respect DTC Transactions correctly
[
https://issues.apache.org/jira/browse/AMQNET-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remo Gloor updated AMQNET-413:
--
Patch Info: Patch Available
> Message producers do not respect DTC Transactions correctly
> ---
>
> Key: AMQNET-413
> URL: https://issues.apache.org/jira/browse/AMQNET-413
> Project: ActiveMQ .Net
> Issue Type: Bug
>Reporter: Remo Gloor
>Assignee: Jim Gomes
>Priority: Critical
> Attachments: allDTCImprovments.patch,
> AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
> AMQNET-413.patch
>
>
> When consuming messages in a transaction and sending new ones during
> processing of that message and the transaction is rolled back and commited on
> retry the number of published messages should be equal to the received one.
> But the number of sent message is bigger than the number of received ones.
> This means some of the message sends are not rolled back others are.
> EDIT: Further analysis have shown that the TransactionContext.TransactionId
> is null when sending eventhough a transaction is in progress and not yet
> completed. It must incorrectly be assigned to null somewhere.
> The following application demonstrates the problem when enqueuing 100+
> messages to foo.bar
> class Program
> {
> private static INetTxSession activeMqSession;
> private static IMessageConsumer consumer;
> private static INetTxConnection connection;
> static void Main(string[] args)
> {
> using (connection = CreateActiveMqConnection())
> using (activeMqSession = connection.CreateNetTxSession())
> using (consumer =
> activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
> "queue://foo.bar")))
> {
> connection.Start();
> while (true)
> {
> try
> {
> using (TransactionScope scoped = new
> TransactionScope(TransactionScopeOption.RequiresNew))
> {
> IMessage msg = null;
> while (msg == null)
> {
> msg = consumer.ReceiveNoWait();
> }
> OnMessage(msg);
> scoped.Complete();
> }
> }
> catch(Exception exception) {}
> }
> }
> }
> private static INetTxConnection CreateActiveMqConnection()
> {
> var connectionFactory = new
> Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
> {
> AcknowledgementMode = AcknowledgementMode.Transactional
> };
> return connectionFactory.CreateNetTxConnection();
> }
> private static void OnMessage(IMessage message)
> {
> var x = new TestSinglePhaseCommit();
> Console.WriteLine("Processing message {0} in transaction {1} -
> {2}", message.NMSMessageId,
> Transaction.Current.TransactionInformation.LocalIdentifier,
> Transaction.Current.TransactionInformation.DistributedIdentifier);
> var session2 = activeMqSession;
> {
> Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
> EnlistmentOptions.None);
> using (var producer =
> session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
> {
> producer.Send(new ActiveMQTextMessage("foo"));
> }
> if (!message.NMSRedelivered) throw new Exception();
> }
> }
> }
> internal class TestSinglePhaseCommit : ISinglePhaseNotification
> {
> public void Prepare(PreparingEnlistment preparingEnlistment)
> {
> preparingEnlistment.Prepared();
> }
> public void Commit(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void Rollback(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void InDoubt(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void SinglePhaseCommit(SinglePhaseEnlistment
> singlePhaseEnlistment)
> {
> singlePhaseEnlistment.Committed();
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQNET-413) Message producers do not respect DTC Transactions correctly
[
https://issues.apache.org/jira/browse/AMQNET-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remo Gloor updated AMQNET-413:
--
Attachment: allDTCImprovments.patch
AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch
> Message producers do not respect DTC Transactions correctly
> ---
>
> Key: AMQNET-413
> URL: https://issues.apache.org/jira/browse/AMQNET-413
> Project: ActiveMQ .Net
> Issue Type: Bug
>Reporter: Remo Gloor
>Assignee: Jim Gomes
>Priority: Critical
> Attachments: allDTCImprovments.patch,
> AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
> AMQNET-413.patch
>
>
> When consuming messages in a transaction and sending new ones during
> processing of that message and the transaction is rolled back and commited on
> retry the number of published messages should be equal to the received one.
> But the number of sent message is bigger than the number of received ones.
> This means some of the message sends are not rolled back others are.
> EDIT: Further analysis have shown that the TransactionContext.TransactionId
> is null when sending eventhough a transaction is in progress and not yet
> completed. It must incorrectly be assigned to null somewhere.
> The following application demonstrates the problem when enqueuing 100+
> messages to foo.bar
> class Program
> {
> private static INetTxSession activeMqSession;
> private static IMessageConsumer consumer;
> private static INetTxConnection connection;
> static void Main(string[] args)
> {
> using (connection = CreateActiveMqConnection())
> using (activeMqSession = connection.CreateNetTxSession())
> using (consumer =
> activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
> "queue://foo.bar")))
> {
> connection.Start();
> while (true)
> {
> try
> {
> using (TransactionScope scoped = new
> TransactionScope(TransactionScopeOption.RequiresNew))
> {
> IMessage msg = null;
> while (msg == null)
> {
> msg = consumer.ReceiveNoWait();
> }
> OnMessage(msg);
> scoped.Complete();
> }
> }
> catch(Exception exception) {}
> }
> }
> }
> private static INetTxConnection CreateActiveMqConnection()
> {
> var connectionFactory = new
> Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
> {
> AcknowledgementMode = AcknowledgementMode.Transactional
> };
> return connectionFactory.CreateNetTxConnection();
> }
> private static void OnMessage(IMessage message)
> {
> var x = new TestSinglePhaseCommit();
> Console.WriteLine("Processing message {0} in transaction {1} -
> {2}", message.NMSMessageId,
> Transaction.Current.TransactionInformation.LocalIdentifier,
> Transaction.Current.TransactionInformation.DistributedIdentifier);
> var session2 = activeMqSession;
> {
> Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
> EnlistmentOptions.None);
> using (var producer =
> session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
> {
> producer.Send(new ActiveMQTextMessage("foo"));
> }
> if (!message.NMSRedelivered) throw new Exception();
> }
> }
> }
> internal class TestSinglePhaseCommit : ISinglePhaseNotification
> {
> public void Prepare(PreparingEnlistment preparingEnlistment)
> {
> preparingEnlistment.Prepared();
> }
> public void Commit(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void Rollback(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void InDoubt(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void SinglePhaseCommit(SinglePhaseEnlistment
> singlePhaseEnlistment)
> {
> singlePhaseEnlistment.Committed();
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian
[jira] [Updated] (AMQNET-420) Session does not pass correct last delivered message in the Remove Info
[ https://issues.apache.org/jira/browse/AMQNET-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-420: -- Attachment: SessionDidNotPassCorrectLastProcessedMessageOnCloseWithRemoveInfo.patch allDTCImprovments.patch > Session does not pass correct last delivered message in the Remove Info > --- > > Key: AMQNET-420 > URL: https://issues.apache.org/jira/browse/AMQNET-420 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: Remo Gloor >Assignee: Jim Gomes >Priority: Critical > Attachments: allDTCImprovments.patch, > SessionDidNotPassCorrectLastProcessedMessageOnCloseWithRemoveInfo.patch > > > The session always passes 0 as the last processed message when disposed. Due > to this problem all messages are marked as delivered once more. When this > happens to many times they wont be delivered at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQNET-420) Session does not pass correct last delivered message in the Remove Info
Remo Gloor created AMQNET-420: - Summary: Session does not pass correct last delivered message in the Remove Info Key: AMQNET-420 URL: https://issues.apache.org/jira/browse/AMQNET-420 Project: ActiveMQ .Net Issue Type: Bug Reporter: Remo Gloor Assignee: Jim Gomes Priority: Critical The session always passes 0 as the last processed message when disposed. Due to this problem all messages are marked as delivered once more. When this happens to many times they wont be delivered at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQNET-419) The MessageConsumer sometimes does not send a RemoveInfo when closed
[ https://issues.apache.org/jira/browse/AMQNET-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-419: -- Attachment: MessageConsumerDidNotGiveBackUnconsumedMessagesCorrectlyOnDispose.patch allDTCImprovments.patch > The MessageConsumer sometimes does not send a RemoveInfo when closed > - > > Key: AMQNET-419 > URL: https://issues.apache.org/jira/browse/AMQNET-419 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: Remo Gloor >Assignee: Jim Gomes >Priority: Critical > Attachments: allDTCImprovments.patch, > MessageConsumerDidNotGiveBackUnconsumedMessagesCorrectlyOnDispose.patch > > > Due to a race condition the Message consumer does not send a RemoveInfo. As a > result the messages are marked as delivered once more. When this happens to > many times the message won't be delivered at all. > Unittest TestCaseRedeliveredCase2 randomly fails because of that problem -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQNET-419) The MessageConsumer sometimes does not send a RemoveInfo when closed
Remo Gloor created AMQNET-419: - Summary: The MessageConsumer sometimes does not send a RemoveInfo when closed Key: AMQNET-419 URL: https://issues.apache.org/jira/browse/AMQNET-419 Project: ActiveMQ .Net Issue Type: Bug Reporter: Remo Gloor Assignee: Jim Gomes Priority: Critical Due to a race condition the Message consumer does not send a RemoveInfo. As a result the messages are marked as delivered once more. When this happens to many times the message won't be delivered at all. Unittest TestCaseRedeliveredCase2 randomly fails because of that problem -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQNET-412) Messages are enlisted to the wrong transaction
[
https://issues.apache.org/jira/browse/AMQNET-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remo Gloor updated AMQNET-412:
--
Patch Info: Patch Available
> Messages are enlisted to the wrong transaction
> --
>
> Key: AMQNET-412
> URL: https://issues.apache.org/jira/browse/AMQNET-412
> Project: ActiveMQ .Net
> Issue Type: Bug
> Environment: Apache.NMS.ActiveMq 1.5.7
>Reporter: Remo Gloor
>Assignee: Jim Gomes
>Priority: Critical
> Attachments: allDTCImprovments.patch,
> MessagesAreEnlistedToTheWrongTransaction.patch
>
>
> Under load active mq enlists a message to a previous transactions. This leads
> to very strange behaviors:
> - Database is updated and message is rolled back
> - Message is completed but database rolledback
> All this results in an invalid system state making. DTC is not usable this
> way.
> Analysis of the source code have shown that the problem is in
> NetTxSession.DoStartTransaction There it checks if a .NET Transaction in the
> TransactionContext. In this case it adds the message to that transaction. But
> this can be the previous transaction because DTC 2-PhaseCommit is
> asyncronous. It needs to check if the Current Transaction is the same as one
> before and wait if they do not match.
> The following applacation demonstrates the problem when enough messages are
> processed E.g. enqueue 100 msg in foo.bar. It is basically
> TestRedeliveredCase3 but with half of the messages failing.
> Whenever a SinglePhaseCommit occurs in the TestSinglePhaseCommit this means
> the database would be commited in an own transaction.
> class Program
> {
> private static INetTxSession activeMqSession;
> private static IMessageConsumer consumer;
> private static INetTxConnection connection;
> static void Main(string[] args)
> {
> using (connection = CreateActiveMqConnection())
> using (activeMqSession = connection.CreateNetTxSession())
> using (consumer =
> activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
> "queue://foo.bar")))
> {
> connection.Start();
> while (true)
> {
> try
> {
> using (TransactionScope scoped = new
> TransactionScope(TransactionScopeOption.RequiresNew))
> {
> IMessage msg = null;
> while (msg == null)
> {
> msg = consumer.ReceiveNoWait();
> }
> OnMessage(msg);
> scoped.Complete();
> }
> }
> catch(Exception exception) {}
> }
> }
> }
> private static INetTxConnection CreateActiveMqConnection()
> {
> var connectionFactory = new
> Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
> {
> AcknowledgementMode = AcknowledgementMode.Transactional
> };
> return connectionFactory.CreateNetTxConnection();
> }
> private static void OnMessage(IMessage message)
> {
> var x = new TestSinglePhaseCommit();
> var session2 = activeMqSession;
> {
> Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
> EnlistmentOptions.None);
> using (var producer =
> session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
> {
> producer.Send(new ActiveMQTextMessage("foo"));
> }
> if (new Random().Next(2) == 0) throw new Exception();
> }
> }
> }
> internal class TestSinglePhaseCommit : ISinglePhaseNotification
> {
> public void Prepare(PreparingEnlistment preparingEnlistment)
> {
> Console.WriteLine("Tx Prepare");
> preparingEnlistment.Prepared();
> }
> public void Commit(Enlistment enlistment)
> {
> Console.WriteLine("Tx Commit");
> enlistment.Done();
> }
> public void Rollback(Enlistment enlistment)
> {
> Console.WriteLine("Tx Rollback");
> enlistment.Done();
> }
> public void InDoubt(Enlistment enlistment)
> {
> Console.WriteLine("Tx InDoubt");
> enlistment.Done();
> }
> public void SinglePhaseCommit(SinglePhaseEnlistment
> singlePhaseEnlistment)
> {
> Console.WriteLine("Tx SinglePhaseCommit");
> si
[jira] [Updated] (AMQNET-412) Messages are enlisted to the wrong transaction
[
https://issues.apache.org/jira/browse/AMQNET-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remo Gloor updated AMQNET-412:
--
Attachment: allDTCImprovments.patch
> Messages are enlisted to the wrong transaction
> --
>
> Key: AMQNET-412
> URL: https://issues.apache.org/jira/browse/AMQNET-412
> Project: ActiveMQ .Net
> Issue Type: Bug
> Environment: Apache.NMS.ActiveMq 1.5.7
>Reporter: Remo Gloor
>Assignee: Jim Gomes
>Priority: Critical
> Attachments: allDTCImprovments.patch,
> MessagesAreEnlistedToTheWrongTransaction.patch
>
>
> Under load active mq enlists a message to a previous transactions. This leads
> to very strange behaviors:
> - Database is updated and message is rolled back
> - Message is completed but database rolledback
> All this results in an invalid system state making. DTC is not usable this
> way.
> Analysis of the source code have shown that the problem is in
> NetTxSession.DoStartTransaction There it checks if a .NET Transaction in the
> TransactionContext. In this case it adds the message to that transaction. But
> this can be the previous transaction because DTC 2-PhaseCommit is
> asyncronous. It needs to check if the Current Transaction is the same as one
> before and wait if they do not match.
> The following applacation demonstrates the problem when enough messages are
> processed E.g. enqueue 100 msg in foo.bar. It is basically
> TestRedeliveredCase3 but with half of the messages failing.
> Whenever a SinglePhaseCommit occurs in the TestSinglePhaseCommit this means
> the database would be commited in an own transaction.
> class Program
> {
> private static INetTxSession activeMqSession;
> private static IMessageConsumer consumer;
> private static INetTxConnection connection;
> static void Main(string[] args)
> {
> using (connection = CreateActiveMqConnection())
> using (activeMqSession = connection.CreateNetTxSession())
> using (consumer =
> activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
> "queue://foo.bar")))
> {
> connection.Start();
> while (true)
> {
> try
> {
> using (TransactionScope scoped = new
> TransactionScope(TransactionScopeOption.RequiresNew))
> {
> IMessage msg = null;
> while (msg == null)
> {
> msg = consumer.ReceiveNoWait();
> }
> OnMessage(msg);
> scoped.Complete();
> }
> }
> catch(Exception exception) {}
> }
> }
> }
> private static INetTxConnection CreateActiveMqConnection()
> {
> var connectionFactory = new
> Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
> {
> AcknowledgementMode = AcknowledgementMode.Transactional
> };
> return connectionFactory.CreateNetTxConnection();
> }
> private static void OnMessage(IMessage message)
> {
> var x = new TestSinglePhaseCommit();
> var session2 = activeMqSession;
> {
> Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
> EnlistmentOptions.None);
> using (var producer =
> session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
> {
> producer.Send(new ActiveMQTextMessage("foo"));
> }
> if (new Random().Next(2) == 0) throw new Exception();
> }
> }
> }
> internal class TestSinglePhaseCommit : ISinglePhaseNotification
> {
> public void Prepare(PreparingEnlistment preparingEnlistment)
> {
> Console.WriteLine("Tx Prepare");
> preparingEnlistment.Prepared();
> }
> public void Commit(Enlistment enlistment)
> {
> Console.WriteLine("Tx Commit");
> enlistment.Done();
> }
> public void Rollback(Enlistment enlistment)
> {
> Console.WriteLine("Tx Rollback");
> enlistment.Done();
> }
> public void InDoubt(Enlistment enlistment)
> {
> Console.WriteLine("Tx InDoubt");
> enlistment.Done();
> }
> public void SinglePhaseCommit(SinglePhaseEnlistment
> singlePhaseEnlistment)
> {
> Console.WriteLine("Tx SinglePhaseCommit");
>
[jira] [Updated] (AMQNET-412) Messages are enlisted to the wrong transaction
[
https://issues.apache.org/jira/browse/AMQNET-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remo Gloor updated AMQNET-412:
--
Attachment: MessagesAreEnlistedToTheWrongTransaction.patch
> Messages are enlisted to the wrong transaction
> --
>
> Key: AMQNET-412
> URL: https://issues.apache.org/jira/browse/AMQNET-412
> Project: ActiveMQ .Net
> Issue Type: Bug
> Environment: Apache.NMS.ActiveMq 1.5.7
>Reporter: Remo Gloor
>Assignee: Jim Gomes
>Priority: Critical
> Attachments: allDTCImprovments.patch,
> MessagesAreEnlistedToTheWrongTransaction.patch
>
>
> Under load active mq enlists a message to a previous transactions. This leads
> to very strange behaviors:
> - Database is updated and message is rolled back
> - Message is completed but database rolledback
> All this results in an invalid system state making. DTC is not usable this
> way.
> Analysis of the source code have shown that the problem is in
> NetTxSession.DoStartTransaction There it checks if a .NET Transaction in the
> TransactionContext. In this case it adds the message to that transaction. But
> this can be the previous transaction because DTC 2-PhaseCommit is
> asyncronous. It needs to check if the Current Transaction is the same as one
> before and wait if they do not match.
> The following applacation demonstrates the problem when enough messages are
> processed E.g. enqueue 100 msg in foo.bar. It is basically
> TestRedeliveredCase3 but with half of the messages failing.
> Whenever a SinglePhaseCommit occurs in the TestSinglePhaseCommit this means
> the database would be commited in an own transaction.
> class Program
> {
> private static INetTxSession activeMqSession;
> private static IMessageConsumer consumer;
> private static INetTxConnection connection;
> static void Main(string[] args)
> {
> using (connection = CreateActiveMqConnection())
> using (activeMqSession = connection.CreateNetTxSession())
> using (consumer =
> activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
> "queue://foo.bar")))
> {
> connection.Start();
> while (true)
> {
> try
> {
> using (TransactionScope scoped = new
> TransactionScope(TransactionScopeOption.RequiresNew))
> {
> IMessage msg = null;
> while (msg == null)
> {
> msg = consumer.ReceiveNoWait();
> }
> OnMessage(msg);
> scoped.Complete();
> }
> }
> catch(Exception exception) {}
> }
> }
> }
> private static INetTxConnection CreateActiveMqConnection()
> {
> var connectionFactory = new
> Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
> {
> AcknowledgementMode = AcknowledgementMode.Transactional
> };
> return connectionFactory.CreateNetTxConnection();
> }
> private static void OnMessage(IMessage message)
> {
> var x = new TestSinglePhaseCommit();
> var session2 = activeMqSession;
> {
> Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
> EnlistmentOptions.None);
> using (var producer =
> session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
> {
> producer.Send(new ActiveMQTextMessage("foo"));
> }
> if (new Random().Next(2) == 0) throw new Exception();
> }
> }
> }
> internal class TestSinglePhaseCommit : ISinglePhaseNotification
> {
> public void Prepare(PreparingEnlistment preparingEnlistment)
> {
> Console.WriteLine("Tx Prepare");
> preparingEnlistment.Prepared();
> }
> public void Commit(Enlistment enlistment)
> {
> Console.WriteLine("Tx Commit");
> enlistment.Done();
> }
> public void Rollback(Enlistment enlistment)
> {
> Console.WriteLine("Tx Rollback");
> enlistment.Done();
> }
> public void InDoubt(Enlistment enlistment)
> {
> Console.WriteLine("Tx InDoubt");
> enlistment.Done();
> }
> public void SinglePhaseCommit(SinglePhaseEnlistment
> singlePhaseEnlistment)
> {
> Console.WriteLine("Tx Single
[jira] [Created] (AMQNET-418) Recovery File Logger does not support multiple concurrent transactions
Remo Gloor created AMQNET-418: - Summary: Recovery File Logger does not support multiple concurrent transactions Key: AMQNET-418 URL: https://issues.apache.org/jira/browse/AMQNET-418 Project: ActiveMQ .Net Issue Type: Bug Reporter: Remo Gloor Assignee: Jim Gomes Attachments: allDTCImprovments.patch, RecoveryLoggerDoesNotSupportMultipleTransactions.patch Currently it is not possible to use more than one session if you use DTC Transactions. This is because the RecoveryFileLogger can not handle more than one transaction simultanously. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQNET-418) Recovery File Logger does not support multiple concurrent transactions
[ https://issues.apache.org/jira/browse/AMQNET-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-418: -- Attachment: RecoveryLoggerDoesNotSupportMultipleTransactions.patch > Recovery File Logger does not support multiple concurrent transactions > -- > > Key: AMQNET-418 > URL: https://issues.apache.org/jira/browse/AMQNET-418 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: Remo Gloor >Assignee: Jim Gomes > Attachments: allDTCImprovments.patch, > RecoveryLoggerDoesNotSupportMultipleTransactions.patch > > > Currently it is not possible to use more than one session if you use DTC > Transactions. This is because the RecoveryFileLogger can not handle more than > one transaction simultanously. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQNET-418) Recovery File Logger does not support multiple concurrent transactions
[ https://issues.apache.org/jira/browse/AMQNET-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-418: -- Attachment: allDTCImprovments.patch All DTC fixes in one patch > Recovery File Logger does not support multiple concurrent transactions > -- > > Key: AMQNET-418 > URL: https://issues.apache.org/jira/browse/AMQNET-418 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: Remo Gloor >Assignee: Jim Gomes > Attachments: allDTCImprovments.patch, > RecoveryLoggerDoesNotSupportMultipleTransactions.patch > > > Currently it is not possible to use more than one session if you use DTC > Transactions. This is because the RecoveryFileLogger can not handle more than > one transaction simultanously. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQNET-417) DTC Recovery should be done once for each application start
[ https://issues.apache.org/jira/browse/AMQNET-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-417: -- Attachment: allDTCImprovments.patch All DTC fixes in one patch > DTC Recovery should be done once for each application start > --- > > Key: AMQNET-417 > URL: https://issues.apache.org/jira/browse/AMQNET-417 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: Remo Gloor >Assignee: Jim Gomes >Priority: Critical > Attachments: allDTCImprovments.patch, > DtcRecoveryShouldNotRunAfterConnectionsAreStarted.patch > > > DTC recovery is currently executed when a new session is created. This is not > correct because there can be other sessions that are currently commiting a > transaction. This transactions must not be recovered, otherwise there are > strange behaviors. > The recovery should be done just once foreach ressource manager ID. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQNET-417) DTC Recovery should be done once for each application start
[ https://issues.apache.org/jira/browse/AMQNET-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-417: -- Attachment: DtcRecoveryShouldNotRunAfterConnectionsAreStarted.patch > DTC Recovery should be done once for each application start > --- > > Key: AMQNET-417 > URL: https://issues.apache.org/jira/browse/AMQNET-417 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: Remo Gloor >Assignee: Jim Gomes >Priority: Critical > Attachments: DtcRecoveryShouldNotRunAfterConnectionsAreStarted.patch > > > DTC recovery is currently executed when a new session is created. This is not > correct because there can be other sessions that are currently commiting a > transaction. This transactions must not be recovered, otherwise there are > strange behaviors. > The recovery should be done just once foreach ressource manager ID. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQNET-417) DTC Recovery should be done once for each application start
Remo Gloor created AMQNET-417: - Summary: DTC Recovery should be done once for each application start Key: AMQNET-417 URL: https://issues.apache.org/jira/browse/AMQNET-417 Project: ActiveMQ .Net Issue Type: Bug Reporter: Remo Gloor Assignee: Jim Gomes Priority: Critical Attachments: DtcRecoveryShouldNotRunAfterConnectionsAreStarted.patch DTC recovery is currently executed when a new session is created. This is not correct because there can be other sessions that are currently commiting a transaction. This transactions must not be recovered, otherwise there are strange behaviors. The recovery should be done just once foreach ressource manager ID. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQNET-416) DTC Ressource ManagerID must be confugurable
[ https://issues.apache.org/jira/browse/AMQNET-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-416: -- Attachment: allDTCImprovments.patch All DTC fixes in one patch > DTC Ressource ManagerID must be confugurable > > > Key: AMQNET-416 > URL: https://issues.apache.org/jira/browse/AMQNET-416 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: Remo Gloor >Assignee: Jim Gomes >Priority: Critical > Attachments: allDTCImprovments.patch, > MakeResourceManagerIDConfigurable.patch > > > Currently the ressource manager ID for DTC transactions is set to a value > generated from the Broker ID. With this implementation it is not possible to > have more than one process connected to the same broker because in that case > an exception is thrown when the second process tries to enlist to the > transaction. > I suggest to make this ID configurable by the application. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQNET-416) DTC Ressource ManagerID must be confugurable
Remo Gloor created AMQNET-416: - Summary: DTC Ressource ManagerID must be confugurable Key: AMQNET-416 URL: https://issues.apache.org/jira/browse/AMQNET-416 Project: ActiveMQ .Net Issue Type: Bug Reporter: Remo Gloor Assignee: Jim Gomes Priority: Critical Attachments: MakeResourceManagerIDConfigurable.patch Currently the ressource manager ID for DTC transactions is set to a value generated from the Broker ID. With this implementation it is not possible to have more than one process connected to the same broker because in that case an exception is thrown when the second process tries to enlist to the transaction. I suggest to make this ID configurable by the application. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQNET-416) DTC Ressource ManagerID must be confugurable
[ https://issues.apache.org/jira/browse/AMQNET-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remo Gloor updated AMQNET-416: -- Attachment: MakeResourceManagerIDConfigurable.patch > DTC Ressource ManagerID must be confugurable > > > Key: AMQNET-416 > URL: https://issues.apache.org/jira/browse/AMQNET-416 > Project: ActiveMQ .Net > Issue Type: Bug >Reporter: Remo Gloor >Assignee: Jim Gomes >Priority: Critical > Attachments: MakeResourceManagerIDConfigurable.patch > > > Currently the ressource manager ID for DTC transactions is set to a value > generated from the Broker ID. With this implementation it is not possible to > have more than one process connected to the same broker because in that case > an exception is thrown when the second process tries to enlist to the > transaction. > I suggest to make this ID configurable by the application. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-4337) Messages with AMQ_SCHEDULED_DELAY do not respect transactions
Remo Gloor created AMQ-4337:
---
Summary: Messages with AMQ_SCHEDULED_DELAY do not respect
transactions
Key: AMQ-4337
URL: https://issues.apache.org/jira/browse/AMQ-4337
Project: ActiveMQ
Issue Type: Improvement
Reporter: Remo Gloor
Currently delayed messages are delivered even if the session it was sent in is
rolled back. According to
http://activemq.2283324.n4.nabble.com/AMQ-SCHEDULED-DELAY-and-transactional-boundaries-td4658339.html
this is because the message can be delivered far in the future and the
transaction would take to long.
I don't agree with that argument. The transaction can be short living. It is
only the enqueuing of the delayed message in the broker that has to be part of
the transaction. The delivery to the consumer is not part of the transaction
anymore.
e.g. consider the scenario in the following preudo code:
while (application_runs)
try{
msg = session.Receive();
session.SendDelayed(anotherMessage);
if (random(5) != 0) throw exception;
session.Commit();
} catch { session.Rollback; }
Currently a delayed message is sent for each retry. So we will get a lot more
messages in the future as we would expect. When delayed messages would respect
transactions just the successful ones would be enqueued. The other ones are
rolledback with the transaction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQNET-414) Exception thrown when using DTC in multiple processes connected to the same broker
Remo Gloor created AMQNET-414: - Summary: Exception thrown when using DTC in multiple processes connected to the same broker Key: AMQNET-414 URL: https://issues.apache.org/jira/browse/AMQNET-414 Project: ActiveMQ .Net Issue Type: Bug Reporter: Remo Gloor Assignee: Jim Gomes Priority: Critical When using DTC in multiple processes that access the same broker instance all but the first instance can't enlist to the transaction. All other throw an exception that there is already a resource manager with the same id. This only happens in case another resource manager like a db server is enlisted on the transaction. This happens because they all processes connected to one broker instance use the same resource manager ID. It is a Guid generated from the broker id. I doubt that there is any good ID that is unique to the process instance but still the same on restart (e.g. connection/client id change on reboot). Is there any other? If not the resource manager id has be configurable somehow by the application. An other option (the one that should be prefered) is to enlist as promotable single phase enlistment. But this would require that the ActiveMQ server is responsible for the transaction as soon as it gets promoted. This would require changes in the server itsself though but make the system much more robust. http://msdn.microsoft.com/en-us/library/ms229980(v=vs.80).aspx -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQNET-413) Message producers do not respect DTC Transactions correctly
[
https://issues.apache.org/jira/browse/AMQNET-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13578739#comment-13578739
]
Remo Gloor commented on AMQNET-413:
---
I don't even know the exact reason for this problem. So I can't provide any
patch.
> Message producers do not respect DTC Transactions correctly
> ---
>
> Key: AMQNET-413
> URL: https://issues.apache.org/jira/browse/AMQNET-413
> Project: ActiveMQ .Net
> Issue Type: Bug
>Reporter: Remo Gloor
>Assignee: Jim Gomes
>Priority: Critical
>
> When consuming messages in a transaction and sending new ones during
> processing of that message and the transaction is rolled back and commited on
> retry the number of published messages should be equal to the received one.
> But the number of sent message is bigger than the number of received ones.
> This means some of the message sends are not rolled back others are.
> EDIT: Further analysis have shown that the TransactionContext.TransactionId
> is null when sending eventhough a transaction is in progress and not yet
> completed. It must incorrectly be assigned to null somewhere.
> The following application demonstrates the problem when enqueuing 100+
> messages to foo.bar
> class Program
> {
> private static INetTxSession activeMqSession;
> private static IMessageConsumer consumer;
> private static INetTxConnection connection;
> static void Main(string[] args)
> {
> using (connection = CreateActiveMqConnection())
> using (activeMqSession = connection.CreateNetTxSession())
> using (consumer =
> activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
> "queue://foo.bar")))
> {
> connection.Start();
> while (true)
> {
> try
> {
> using (TransactionScope scoped = new
> TransactionScope(TransactionScopeOption.RequiresNew))
> {
> IMessage msg = null;
> while (msg == null)
> {
> msg = consumer.ReceiveNoWait();
> }
> OnMessage(msg);
> scoped.Complete();
> }
> }
> catch(Exception exception) {}
> }
> }
> }
> private static INetTxConnection CreateActiveMqConnection()
> {
> var connectionFactory = new
> Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
> {
> AcknowledgementMode = AcknowledgementMode.Transactional
> };
> return connectionFactory.CreateNetTxConnection();
> }
> private static void OnMessage(IMessage message)
> {
> var x = new TestSinglePhaseCommit();
> Console.WriteLine("Processing message {0} in transaction {1} -
> {2}", message.NMSMessageId,
> Transaction.Current.TransactionInformation.LocalIdentifier,
> Transaction.Current.TransactionInformation.DistributedIdentifier);
> var session2 = activeMqSession;
> {
> Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
> EnlistmentOptions.None);
> using (var producer =
> session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
> {
> producer.Send(new ActiveMQTextMessage("foo"));
> }
> if (!message.NMSRedelivered) throw new Exception();
> }
> }
> }
> internal class TestSinglePhaseCommit : ISinglePhaseNotification
> {
> public void Prepare(PreparingEnlistment preparingEnlistment)
> {
> preparingEnlistment.Prepared();
> }
> public void Commit(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void Rollback(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void InDoubt(Enlistment enlistment)
> {
> enlistment.Done();
> }
> public void SinglePhaseCommit(SinglePhaseEnlistment
> singlePhaseEnlistment)
> {
> singlePhaseEnlistment.Committed();
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQNET-413) Message producers do not respect DTC Transactions correctly
[
https://issues.apache.org/jira/browse/AMQNET-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remo Gloor updated AMQNET-413:
--
Description:
When consuming messages in a transaction and sending new ones during processing
of that message and the transaction is rolled back and commited on retry the
number of published messages should be equal to the received one.
But the number of sent message is bigger than the number of received ones. This
means some of the message sends are not rolled back others are.
EDIT: Further analysis have shown that the TransactionContext.TransactionId is
null when sending eventhough a transaction is in progress and not yet
completed. It must incorrectly be assigned to null somewhere.
The following application demonstrates the problem when enqueuing 100+ messages
to foo.bar
class Program
{
private static INetTxSession activeMqSession;
private static IMessageConsumer consumer;
private static INetTxConnection connection;
static void Main(string[] args)
{
using (connection = CreateActiveMqConnection())
using (activeMqSession = connection.CreateNetTxSession())
using (consumer =
activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
"queue://foo.bar")))
{
connection.Start();
while (true)
{
try
{
using (TransactionScope scoped = new
TransactionScope(TransactionScopeOption.RequiresNew))
{
IMessage msg = null;
while (msg == null)
{
msg = consumer.ReceiveNoWait();
}
OnMessage(msg);
scoped.Complete();
}
}
catch(Exception exception) {}
}
}
}
private static INetTxConnection CreateActiveMqConnection()
{
var connectionFactory = new
Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
{
AcknowledgementMode = AcknowledgementMode.Transactional
};
return connectionFactory.CreateNetTxConnection();
}
private static void OnMessage(IMessage message)
{
var x = new TestSinglePhaseCommit();
Console.WriteLine("Processing message {0} in transaction {1} -
{2}", message.NMSMessageId,
Transaction.Current.TransactionInformation.LocalIdentifier,
Transaction.Current.TransactionInformation.DistributedIdentifier);
var session2 = activeMqSession;
{
Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
EnlistmentOptions.None);
using (var producer =
session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
{
producer.Send(new ActiveMQTextMessage("foo"));
}
if (!message.NMSRedelivered) throw new Exception();
}
}
}
internal class TestSinglePhaseCommit : ISinglePhaseNotification
{
public void Prepare(PreparingEnlistment preparingEnlistment)
{
preparingEnlistment.Prepared();
}
public void Commit(Enlistment enlistment)
{
enlistment.Done();
}
public void Rollback(Enlistment enlistment)
{
enlistment.Done();
}
public void InDoubt(Enlistment enlistment)
{
enlistment.Done();
}
public void SinglePhaseCommit(SinglePhaseEnlistment
singlePhaseEnlistment)
{
singlePhaseEnlistment.Committed();
}
}
was:
When consuming messages in a transaction and sending new ones during processing
of that message and the transaction is rolled back and commited on retry the
number of published messages should be equal to the received one.
But the number of sent message is bigger than the number of received ones. This
means some of the message sends are not rolled back others are.
The following application demonstrates the problem when enqueuing 100+ messages
to foo.bar
class Program
{
private static INetTxSession activeMqSession;
private static IMessageConsumer consumer;
private static INetTxConnection connection;
static void Main(string[] args)
{
using (connection = CreateActiveMqConnection())
using (activeMqSession = connection.CreateNetTxSession())
using (consumer =
activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
"queue://foo.bar")))
{
connection.Start();
[jira] [Created] (AMQNET-413) Message producers do not respect DTC Transactions correctly
Remo Gloor created AMQNET-413:
-
Summary: Message producers do not respect DTC Transactions
correctly
Key: AMQNET-413
URL: https://issues.apache.org/jira/browse/AMQNET-413
Project: ActiveMQ .Net
Issue Type: Bug
Reporter: Remo Gloor
Assignee: Jim Gomes
Priority: Critical
When consuming messages in a transaction and sending new ones during processing
of that message and the transaction is rolled back and commited on retry the
number of published messages should be equal to the received one.
But the number of sent message is bigger than the number of received ones. This
means some of the message sends are not rolled back others are.
The following application demonstrates the problem when enqueuing 100+ messages
to foo.bar
class Program
{
private static INetTxSession activeMqSession;
private static IMessageConsumer consumer;
private static INetTxConnection connection;
static void Main(string[] args)
{
using (connection = CreateActiveMqConnection())
using (activeMqSession = connection.CreateNetTxSession())
using (consumer =
activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
"queue://foo.bar")))
{
connection.Start();
while (true)
{
try
{
using (TransactionScope scoped = new
TransactionScope(TransactionScopeOption.RequiresNew))
{
IMessage msg = null;
while (msg == null)
{
msg = consumer.ReceiveNoWait();
}
OnMessage(msg);
scoped.Complete();
}
}
catch(Exception exception) {}
}
}
}
private static INetTxConnection CreateActiveMqConnection()
{
var connectionFactory = new
Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
{
AcknowledgementMode = AcknowledgementMode.Transactional
};
return connectionFactory.CreateNetTxConnection();
}
private static void OnMessage(IMessage message)
{
var x = new TestSinglePhaseCommit();
Console.WriteLine("Processing message {0} in transaction {1} -
{2}", message.NMSMessageId,
Transaction.Current.TransactionInformation.LocalIdentifier,
Transaction.Current.TransactionInformation.DistributedIdentifier);
var session2 = activeMqSession;
{
Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
EnlistmentOptions.None);
using (var producer =
session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
{
producer.Send(new ActiveMQTextMessage("foo"));
}
if (!message.NMSRedelivered) throw new Exception();
}
}
}
internal class TestSinglePhaseCommit : ISinglePhaseNotification
{
public void Prepare(PreparingEnlistment preparingEnlistment)
{
preparingEnlistment.Prepared();
}
public void Commit(Enlistment enlistment)
{
enlistment.Done();
}
public void Rollback(Enlistment enlistment)
{
enlistment.Done();
}
public void InDoubt(Enlistment enlistment)
{
enlistment.Done();
}
public void SinglePhaseCommit(SinglePhaseEnlistment
singlePhaseEnlistment)
{
singlePhaseEnlistment.Committed();
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQNET-412) Messages are enlisted to the wrong transaction
[
https://issues.apache.org/jira/browse/AMQNET-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13578620#comment-13578620
]
Remo Gloor commented on AMQNET-412:
---
Unit testing is impossible because it in not deterministic. Is would fail
sometimes and be succesful in other cases.
> Messages are enlisted to the wrong transaction
> --
>
> Key: AMQNET-412
> URL: https://issues.apache.org/jira/browse/AMQNET-412
> Project: ActiveMQ .Net
> Issue Type: Bug
> Environment: Apache.NMS.ActiveMq 1.5.7
>Reporter: Remo Gloor
>Assignee: Jim Gomes
>Priority: Critical
>
> Under load active mq enlists a message to a previous transactions. This leads
> to very strange behaviors:
> - Database is updated and message is rolled back
> - Message is completed but database rolledback
> All this results in an invalid system state making. DTC is not usable this
> way.
> Analysis of the source code have shown that the problem is in
> NetTxSession.DoStartTransaction There it checks if a .NET Transaction in the
> TransactionContext. In this case it adds the message to that transaction. But
> this can be the previous transaction because DTC 2-PhaseCommit is
> asyncronous. It needs to check if the Current Transaction is the same as one
> before and wait if they do not match.
> The following applacation demonstrates the problem when enough messages are
> processed E.g. enqueue 100 msg in foo.bar. It is basically
> TestRedeliveredCase3 but with half of the messages failing.
> Whenever a SinglePhaseCommit occurs in the TestSinglePhaseCommit this means
> the database would be commited in an own transaction.
> class Program
> {
> private static INetTxSession activeMqSession;
> private static IMessageConsumer consumer;
> private static INetTxConnection connection;
> static void Main(string[] args)
> {
> using (connection = CreateActiveMqConnection())
> using (activeMqSession = connection.CreateNetTxSession())
> using (consumer =
> activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
> "queue://foo.bar")))
> {
> connection.Start();
> while (true)
> {
> try
> {
> using (TransactionScope scoped = new
> TransactionScope(TransactionScopeOption.RequiresNew))
> {
> IMessage msg = null;
> while (msg == null)
> {
> msg = consumer.ReceiveNoWait();
> }
> OnMessage(msg);
> scoped.Complete();
> }
> }
> catch(Exception exception) {}
> }
> }
> }
> private static INetTxConnection CreateActiveMqConnection()
> {
> var connectionFactory = new
> Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
> {
> AcknowledgementMode = AcknowledgementMode.Transactional
> };
> return connectionFactory.CreateNetTxConnection();
> }
> private static void OnMessage(IMessage message)
> {
> var x = new TestSinglePhaseCommit();
> var session2 = activeMqSession;
> {
> Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
> EnlistmentOptions.None);
> using (var producer =
> session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
> {
> producer.Send(new ActiveMQTextMessage("foo"));
> }
> if (new Random().Next(2) == 0) throw new Exception();
> }
> }
> }
> internal class TestSinglePhaseCommit : ISinglePhaseNotification
> {
> public void Prepare(PreparingEnlistment preparingEnlistment)
> {
> Console.WriteLine("Tx Prepare");
> preparingEnlistment.Prepared();
> }
> public void Commit(Enlistment enlistment)
> {
> Console.WriteLine("Tx Commit");
> enlistment.Done();
> }
> public void Rollback(Enlistment enlistment)
> {
> Console.WriteLine("Tx Rollback");
> enlistment.Done();
> }
> public void InDoubt(Enlistment enlistment)
> {
> Console.WriteLine("Tx InDoubt");
> enlistment.Done();
> }
> public void SinglePhaseCommit(SinglePhaseEnlistment
> singlePhaseEnlistment)
> {
> Cons
[jira] [Comment Edited] (AMQNET-412) Messages are enlisted to the wrong transaction
[
https://issues.apache.org/jira/browse/AMQNET-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13578620#comment-13578620
]
Remo Gloor edited comment on AMQNET-412 at 2/14/13 7:59 PM:
Unit testing is impossible because it is not deterministic. Is would fail
sometimes and be succesful in other cases.
was (Author: remogloor):
Unit testing is impossible because it in not deterministic. Is would fail
sometimes and be succesful in other cases.
> Messages are enlisted to the wrong transaction
> --
>
> Key: AMQNET-412
> URL: https://issues.apache.org/jira/browse/AMQNET-412
> Project: ActiveMQ .Net
> Issue Type: Bug
> Environment: Apache.NMS.ActiveMq 1.5.7
>Reporter: Remo Gloor
>Assignee: Jim Gomes
>Priority: Critical
>
> Under load active mq enlists a message to a previous transactions. This leads
> to very strange behaviors:
> - Database is updated and message is rolled back
> - Message is completed but database rolledback
> All this results in an invalid system state making. DTC is not usable this
> way.
> Analysis of the source code have shown that the problem is in
> NetTxSession.DoStartTransaction There it checks if a .NET Transaction in the
> TransactionContext. In this case it adds the message to that transaction. But
> this can be the previous transaction because DTC 2-PhaseCommit is
> asyncronous. It needs to check if the Current Transaction is the same as one
> before and wait if they do not match.
> The following applacation demonstrates the problem when enough messages are
> processed E.g. enqueue 100 msg in foo.bar. It is basically
> TestRedeliveredCase3 but with half of the messages failing.
> Whenever a SinglePhaseCommit occurs in the TestSinglePhaseCommit this means
> the database would be commited in an own transaction.
> class Program
> {
> private static INetTxSession activeMqSession;
> private static IMessageConsumer consumer;
> private static INetTxConnection connection;
> static void Main(string[] args)
> {
> using (connection = CreateActiveMqConnection())
> using (activeMqSession = connection.CreateNetTxSession())
> using (consumer =
> activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
> "queue://foo.bar")))
> {
> connection.Start();
> while (true)
> {
> try
> {
> using (TransactionScope scoped = new
> TransactionScope(TransactionScopeOption.RequiresNew))
> {
> IMessage msg = null;
> while (msg == null)
> {
> msg = consumer.ReceiveNoWait();
> }
> OnMessage(msg);
> scoped.Complete();
> }
> }
> catch(Exception exception) {}
> }
> }
> }
> private static INetTxConnection CreateActiveMqConnection()
> {
> var connectionFactory = new
> Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
> {
> AcknowledgementMode = AcknowledgementMode.Transactional
> };
> return connectionFactory.CreateNetTxConnection();
> }
> private static void OnMessage(IMessage message)
> {
> var x = new TestSinglePhaseCommit();
> var session2 = activeMqSession;
> {
> Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
> EnlistmentOptions.None);
> using (var producer =
> session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
> {
> producer.Send(new ActiveMQTextMessage("foo"));
> }
> if (new Random().Next(2) == 0) throw new Exception();
> }
> }
> }
> internal class TestSinglePhaseCommit : ISinglePhaseNotification
> {
> public void Prepare(PreparingEnlistment preparingEnlistment)
> {
> Console.WriteLine("Tx Prepare");
> preparingEnlistment.Prepared();
> }
> public void Commit(Enlistment enlistment)
> {
> Console.WriteLine("Tx Commit");
> enlistment.Done();
> }
> public void Rollback(Enlistment enlistment)
> {
> Console.WriteLine("Tx Rollback");
> enlistment.Done();
> }
> public void InDoubt(Enlistment enlistment)
>
[jira] [Updated] (AMQNET-412) Messages are enlisted to the wrong transaction
[
https://issues.apache.org/jira/browse/AMQNET-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remo Gloor updated AMQNET-412:
--
Description:
Under load active mq enlists a message to a previous transactions. This leads
to very strange behaviors:
- Database is updated and message is rolled back
- Message is completed but database rolledback
All this results in an invalid system state making. DTC is not usable this way.
Analysis of the source code have shown that the problem is in
NetTxSession.DoStartTransaction There it checks if a .NET Transaction in the
TransactionContext. In this case it adds the message to that transaction. But
this can be the previous transaction because DTC 2-PhaseCommit is asyncronous.
It needs to check if the Current Transaction is the same as one before and wait
if they do not match.
The following applacation demonstrates the problem when enough messages are
processed E.g. enqueue 100 msg in foo.bar. It is basically TestRedeliveredCase3
but with half of the messages failing.
Whenever a SinglePhaseCommit occurs in the TestSinglePhaseCommit this means the
database would be commited in an own transaction.
class Program
{
private static INetTxSession activeMqSession;
private static IMessageConsumer consumer;
private static INetTxConnection connection;
static void Main(string[] args)
{
using (connection = CreateActiveMqConnection())
using (activeMqSession = connection.CreateNetTxSession())
using (consumer =
activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
"queue://foo.bar")))
{
connection.Start();
while (true)
{
try
{
using (TransactionScope scoped = new
TransactionScope(TransactionScopeOption.RequiresNew))
{
IMessage msg = null;
while (msg == null)
{
msg = consumer.ReceiveNoWait();
}
OnMessage(msg);
scoped.Complete();
}
}
catch(Exception exception) {}
}
}
}
private static INetTxConnection CreateActiveMqConnection()
{
var connectionFactory = new
Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
{
AcknowledgementMode = AcknowledgementMode.Transactional
};
return connectionFactory.CreateNetTxConnection();
}
private static void OnMessage(IMessage message)
{
var x = new TestSinglePhaseCommit();
var session2 = activeMqSession;
{
Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
EnlistmentOptions.None);
using (var producer =
session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
{
producer.Send(new ActiveMQTextMessage("foo"));
}
if (new Random().Next(2) == 0) throw new Exception();
}
}
}
internal class TestSinglePhaseCommit : ISinglePhaseNotification
{
public void Prepare(PreparingEnlistment preparingEnlistment)
{
Console.WriteLine("Tx Prepare");
preparingEnlistment.Prepared();
}
public void Commit(Enlistment enlistment)
{
Console.WriteLine("Tx Commit");
enlistment.Done();
}
public void Rollback(Enlistment enlistment)
{
Console.WriteLine("Tx Rollback");
enlistment.Done();
}
public void InDoubt(Enlistment enlistment)
{
Console.WriteLine("Tx InDoubt");
enlistment.Done();
}
public void SinglePhaseCommit(SinglePhaseEnlistment
singlePhaseEnlistment)
{
Console.WriteLine("Tx SinglePhaseCommit");
singlePhaseEnlistment.Committed();
}
}
was:
Under load active mq enlists a message to a previous transactions. This leads
to very strange behaviors:
- Database is updated and message is rolled back
- Message is completed but database rolledback
All this results in an invalid system state making. DTC is not usable this way.
Analysis of the source code have shown that the problem is in
NetTxSession.DoStartTransaction There it checks if a .NET Transaction in the
TransactionContext. In this case it adds the message to that transaction. But
this can be the previous transaction because DTC 2-PhaseCommit is asyncronous.
It needs to check if the Current Transaction is the same as one before and wait
if the
[jira] [Created] (AMQNET-412) Messages are enlisted to the wrong transaction
Remo Gloor created AMQNET-412:
-
Summary: Messages are enlisted to the wrong transaction
Key: AMQNET-412
URL: https://issues.apache.org/jira/browse/AMQNET-412
Project: ActiveMQ .Net
Issue Type: Bug
Environment: Apache.NMS.ActiveMq 1.5.7
Reporter: Remo Gloor
Assignee: Jim Gomes
Priority: Critical
Under load active mq enlists a message to a previous transactions. This leads
to very strange behaviors:
- Database is updated and message is rolled back
- Message is completed but database rolledback
All this results in an invalid system state making. DTC is not usable this way.
Analysis of the source code have shown that the problem is in
NetTxSession.DoStartTransaction There it checks if a .NET Transaction in the
TransactionContext. In this case it adds the message to that transaction. But
this can be the previous transaction because DTC 2-PhaseCommit is asyncronous.
It needs to check if the Current Transaction is the same as one before and wait
if they do not match.
The following applacation demonstrates the problem when enough messages are
processed E.g. enqueue 100 msg in foo.bar. It is basically TestRedeliveredCase3
but with half of the messages failing.
Whenever a SinglePhaseCommit occurs in the TestSinglePhaseCommit this means the
database would be commited in an own transaction.
class Program
{
private static INetTxSession activeMqSession;
private static IMessageConsumer consumer;
private static INetTxConnection connection;
static void Main(string[] args)
{
using (connection = CreateActiveMqConnection())
using (activeMqSession = connection.CreateNetTxSession())
using (consumer =
activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
"queue://foo.bar")))
{
connection.Start();
while (true)
{
try
{
using (TransactionScope scoped = new
TransactionScope(TransactionScopeOption.RequiresNew))
{
IMessage msg = null;
while (msg == null)
{
msg = consumer.ReceiveNoWait();
}
OnMessage(msg);
scoped.Complete();
}
}
catch(Exception exception) {}
}
}
}
private static INetTxConnection CreateActiveMqConnection()
{
var connectionFactory = new
Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
{
AcknowledgementMode = AcknowledgementMode.Transactional
};
return connectionFactory.CreateNetTxConnection();
}
private static void OnMessage(IMessage message)
{
var x = new TestSinglePhaseCommit();
var session2 = activeMqSession;
{
Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
EnlistmentOptions.None);
// The proble occurs only if a message is sent using the same
session like the receiver
using (var producer =
session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
{
producer.Send(new ActiveMQTextMessage("foo"));
}
if (new Random().Next(2) == 0) throw new Exception();
}
}
}
internal class TestSinglePhaseCommit : ISinglePhaseNotification
{
public void Prepare(PreparingEnlistment preparingEnlistment)
{
Console.WriteLine("Tx Prepare");
preparingEnlistment.Prepared();
}
public void Commit(Enlistment enlistment)
{
Console.WriteLine("Tx Commit");
enlistment.Done();
}
public void Rollback(Enlistment enlistment)
{
Console.WriteLine("Tx Rollback");
enlistment.Done();
}
public void InDoubt(Enlistment enlistment)
{
Console.WriteLine("Tx InDoubt");
enlistment.Done();
}
public void SinglePhaseCommit(SinglePhaseEnlistment
singlePhaseEnlistment)
{
Console.WriteLine("Tx SinglePhaseCommit");
singlePhaseEnlistment.Committed();
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQNET-406) Messages for rollbacked transactions are dequeued
Remo Gloor created AMQNET-406:
-
Summary: Messages for rollbacked transactions are dequeued
Key: AMQNET-406
URL: https://issues.apache.org/jira/browse/AMQNET-406
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Reporter: Remo Gloor
Assignee: Jim Gomes
When a transaction scope is not Completed then the message should not be
dequeued. In this case the message should be rollback and retried.
This little program shouldn't dequeue any message and the message should end in
the DLQ:
static void Main()
{
using (var connection =
CreateConnectionFactory().CreateNetTxConnection())
using (var session = connection.CreateSession())
using (var consumer =
session.CreateConsumer(session.GetQueue("test")))
{
connection.Start();
consumer.Listener += OnMessage;
Console.ReadKey();
}
}
private static void OnMessage(IMessage message)
{
using (var tx = new TransactionScope())
{
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQNET-405) Messages are not dequeued when using Two Phase Commit for DTC Transaction
Remo Gloor created AMQNET-405:
-
Summary: Messages are not dequeued when using Two Phase Commit for
DTC Transaction
Key: AMQNET-405
URL: https://issues.apache.org/jira/browse/AMQNET-405
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Affects Versions: 1.5.6
Environment: Windows 7, AMQ 5.7
Reporter: Remo Gloor
Assignee: Jim Gomes
Priority: Critical
Messages are not removed from the queue even though they are processes
correctly in the following scenaro:
Create a NetTxConnection and NetTxSession. Create a consumer for some queue and
register the Listener event. Create a new TransactionScope in the event
handler. Inside the consumer you send a new message to some other queue using
the session of the consumer. Do now some action that uses the Distributed
Transaction from another system (e.g. writing to a database) to force that two
phase commit is used instead of Single Phase Commit. Complete the and dispose
the TransactionScope.
I'd expect that that the sent message is delivered to the queue, the database
is modified and the received message is removed from the input queue. But the
behavior is that the last expectation is not met. The message remains in the
input queue.
If you use an own session for sending the messages the problem does not occur.
But this has the disadvantage the you will always do two phase commits even if
AMQ is the only system that takes part in the Distrubuted Transaction.
Code demonstrating the problem:
namespace ConsoleApplication1
{
using System;
using System.Transactions;
using Apache.NMS;
using Apache.NMS.ActiveMQ.Commands;
using Apache.NMS.Util;
class Program
{
private static INetTxSession activeMqSession;
private static IMessageConsumer consumer;
private static INetTxConnection connection;
static void Main(string[] args)
{
using (connection = CreateActiveMqConnection())
using (activeMqSession = connection.CreateNetTxSession())
using (consumer =
activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
"queue://foo.bar")))
{
consumer.Listener += OnMessage;
connection.Start();
Console.WriteLine("Started");
Console.WriteLine("Press any key to exit");
Console.ReadKey();
}
}
private static INetTxConnection CreateActiveMqConnection()
{
var connectionFactory = new
Apache.NMS.ActiveMQ.NetTxConnectionFactory("activemq:tcp://localhost:61616")
{
AcknowledgementMode = AcknowledgementMode.Transactional
};
return connectionFactory.CreateNetTxConnection();
}
private static void OnMessage(IMessage message)
{
var x = new TestSinglePhaseCommit();
using (var session2 = connection.CreateNetTxSession())
using (var tx = new
TransactionScope(TransactionScopeOption.RequiresNew))
{
Console.WriteLine("Message Received");
// Force two phase commit, In reality this happens by using
another system that takes part in the
// distributed transaction like a database.
Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
EnlistmentOptions.None);
// The proble occurs only if a message is sent using the same
session like the receiver
using (var producer =
session2.CreateProducer(SessionUtil.GetQueue(session2, "queue://foo.baz")))
{
producer.Send(new ActiveMQTextMessage("foo"));
}
tx.Complete();
}
}
}
internal class TestSinglePhaseCommit : ISinglePhaseNotification
{
public void Prepare(PreparingEnlistment preparingEnlistment)
{
preparingEnlistment.Prepared();
}
public void Commit(Enlistment enlistment)
{
enlistment.Done();
}
public void Rollback(Enlistment enlistment)
{
enlistment.Done();
}
public void InDoubt(Enlistment enlistment)
{
enlistment.Done();
}
public void SinglePhaseCommit(SinglePhaseEnlistment
singlePhaseEnlistment)
{
singlePhaseEnlistment.Committed();
}
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
