[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-tabpanelfocusedCommentId=13777466#comment-13777466 ] Daniel Marbach commented on AMQNET-418: --- Tom, nobody seems to care about the patches we provided. 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-422) Added support for transactions for Asyncronous Listeners
[
https://issues.apache.org/jira/browse/AMQNET-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777462#comment-13777462
]
Daniel Marbach commented on AMQNET-422:
---
Tom, nobody seems to care about the patches we provided.
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.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] [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-tabpanelfocusedCommentId=13662703#comment-13662703
]
Daniel Marbach commented on AMQNET-413:
---
Why is it closed when incomplete???
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-tabpanelfocusedCommentId=13659907#comment-13659907 ] Daniel Marbach commented on AMQNET-416: --- Nice!. Thanks a lot! 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: Timothy Bish Priority: Critical Fix For: 1.6.0 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] [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-tabpanelfocusedCommentId=13649309#comment-13649309 ] Daniel Marbach commented on AMQNET-416: --- Yes it introduces more locking overhead because the original code has some serious multi threading issues which we discovered and fixed. 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] [Commented] (AMQNET-433) Correctly rethrow exceptions without swallowing the stack trace
[
https://issues.apache.org/jira/browse/AMQNET-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13645292#comment-13645292
]
Daniel Marbach commented on AMQNET-433:
---
Hy Jim,
That is what I consider a correct and detailed answer which I find much more
polite.
Daniel
Correctly rethrow exceptions without swallowing the stack trace
---
Key: AMQNET-433
URL: https://issues.apache.org/jira/browse/AMQNET-433
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Reporter: Daniel Marbach
Assignee: Jim Gomes
Priority: Trivial
Fix For: 1.6.0
When looking through the code I saw a lot of the following code snippets:
try
{
}
catch(AnyException ex)
{
// do something
throw ex;
}
This WILL rewrite the stack trace and is not considered best practice. I
suggest you change the appropriate places in the code to:
try
{
}
catch(AnyException ex)
{
// do something
throw;
}
--
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-434) FailoverTransport Memory Leak with TransactionState
[ https://issues.apache.org/jira/browse/AMQNET-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13645293#comment-13645293 ] Daniel Marbach commented on AMQNET-434: --- We found the root cause of the problem. Will add a patch FailoverTransport Memory Leak with TransactionState --- Key: AMQNET-434 URL: https://issues.apache.org/jira/browse/AMQNET-434 Project: ActiveMQ .Net Issue Type: Bug Affects Versions: 1.5.6 Reporter: Daniel Marbach Assignee: Timothy Bish Fix For: 1.6.0 Attachments: ConnectionStateTrackerMemoryLeak.cs I'm hunting down a possible memory leak. We have the following problem in production: when the consumer/subscriber endpoint runs for a long time with failover transport enabled the memory grows indefinitely. I used YouTrack and AntsProfiler to hunt down the issues. The retention path I see in production is the following: The FailoverTransport nested class FailoverTask has two ConnectionStateTrackers this keeps a dictionary which links the ConnectionId to the ConnectionState. The ConnectionState itself has a dictionary which links the transactionId to the TransactionState. The TranscationState tracks commands. BUT these commands are never freed up from the transaction state and stay there forever which will blow up the memory some time. I'm currently investigation how to fix this but must first properly understand the code. I opened up this issue in the hope that it will ring a bell for you guys. Daniel -- 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-434) FailoverTransport Memory Leak with TransactionState
[ https://issues.apache.org/jira/browse/AMQNET-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Marbach updated AMQNET-434: -- Attachment: ConnectionStateTrackerMemoryLeak.cs Fixes removal of TransactionState in DTC case FailoverTransport Memory Leak with TransactionState --- Key: AMQNET-434 URL: https://issues.apache.org/jira/browse/AMQNET-434 Project: ActiveMQ .Net Issue Type: Bug Affects Versions: 1.5.6 Reporter: Daniel Marbach Assignee: Timothy Bish Fix For: 1.6.0 Attachments: ConnectionStateTrackerMemoryLeak.cs I'm hunting down a possible memory leak. We have the following problem in production: when the consumer/subscriber endpoint runs for a long time with failover transport enabled the memory grows indefinitely. I used YouTrack and AntsProfiler to hunt down the issues. The retention path I see in production is the following: The FailoverTransport nested class FailoverTask has two ConnectionStateTrackers this keeps a dictionary which links the ConnectionId to the ConnectionState. The ConnectionState itself has a dictionary which links the transactionId to the TransactionState. The TranscationState tracks commands. BUT these commands are never freed up from the transaction state and stay there forever which will blow up the memory some time. I'm currently investigation how to fix this but must first properly understand the code. I opened up this issue in the hope that it will ring a bell for you guys. Daniel -- 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-434) FailoverTransport Memory Leak with TransactionState
[ https://issues.apache.org/jira/browse/AMQNET-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13645295#comment-13645295 ] Daniel Marbach commented on AMQNET-434: --- Sorry the file should be named .patch. Messed that up FailoverTransport Memory Leak with TransactionState --- Key: AMQNET-434 URL: https://issues.apache.org/jira/browse/AMQNET-434 Project: ActiveMQ .Net Issue Type: Bug Affects Versions: 1.5.6 Reporter: Daniel Marbach Assignee: Timothy Bish Fix For: 1.6.0 Attachments: ConnectionStateTrackerMemoryLeak.cs I'm hunting down a possible memory leak. We have the following problem in production: when the consumer/subscriber endpoint runs for a long time with failover transport enabled the memory grows indefinitely. I used YouTrack and AntsProfiler to hunt down the issues. The retention path I see in production is the following: The FailoverTransport nested class FailoverTask has two ConnectionStateTrackers this keeps a dictionary which links the ConnectionId to the ConnectionState. The ConnectionState itself has a dictionary which links the transactionId to the TransactionState. The TranscationState tracks commands. BUT these commands are never freed up from the transaction state and stay there forever which will blow up the memory some time. I'm currently investigation how to fix this but must first properly understand the code. I opened up this issue in the hope that it will ring a bell for you guys. Daniel -- 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-433) Correctly rethrow exceptions without swallowing the stack trace
Daniel Marbach created AMQNET-433:
-
Summary: Correctly rethrow exceptions without swallowing the stack
trace
Key: AMQNET-433
URL: https://issues.apache.org/jira/browse/AMQNET-433
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Reporter: Daniel Marbach
Assignee: Jim Gomes
Priority: Trivial
When looking through the code I saw a lot of the following code snippets:
try
{
}
catch(AnyException ex)
{
// do something
throw ex;
}
This WILL rewrite the stack trace and is not considered best practice. I
suggest you change the appropriate places in the code to:
try
{
}
catch(AnyException ex)
{
// do something
throw;
}
--
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-tabpanelfocusedCommentId=13642782#comment-13642782
]
Daniel Marbach commented on AMQNET-413:
---
Any timeline for this issue?
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
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] [Commented] (AMQNET-405) Messages are not dequeued when using Two Phase Commit for DTC Transaction
[
https://issues.apache.org/jira/browse/AMQNET-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642783#comment-13642783
]
Daniel Marbach commented on AMQNET-405:
---
Any timeline for this issue? 413 has patch which fixes that problem.
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
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
[jira] [Commented] (AMQNET-404) ActiveMQByteMessage Content accessing multiple times wipes the property
[
https://issues.apache.org/jira/browse/AMQNET-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642786#comment-13642786
]
Daniel Marbach commented on AMQNET-404:
---
No I didn't call reset. So I close this issue if this is the defined behavior
ActiveMQByteMessage Content accessing multiple times wipes the property
---
Key: AMQNET-404
URL: https://issues.apache.org/jira/browse/AMQNET-404
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Affects Versions: 1.5.6
Reporter: Daniel Marbach
Assignee: Jim Gomes
Priority: Minor
If you have an IBytesMessage and for example do the following:
byte[] content = null;
if (message.Content!= null)
{
content = message.Content;
}
Accessing content the first time will return the correct data.
Accessing a second time the content property will return an empty byte array
which has the length of the data but all bytes are zero.
It is OK that the content property is evaluated lazily but it should not
return different data when accessing multiple times. So accessing the
property the first time should read the buffer and assign it to a field and
then always return that byte buffer.
--
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-434) FailoverTransport Memory Leak with TransactionState
Daniel Marbach created AMQNET-434: - Summary: FailoverTransport Memory Leak with TransactionState Key: AMQNET-434 URL: https://issues.apache.org/jira/browse/AMQNET-434 Project: ActiveMQ .Net Issue Type: Bug Affects Versions: 1.5.6 Reporter: Daniel Marbach Assignee: Jim Gomes I'm hunting down a possible memory leak. We have the following problem in production: when the consumer/subscriber endpoint runs for a long time with failover transport enabled the memory grows indefinitely. I used YouTrack and AntsProfiler to hunt down the issues. The retention path I see in production is the following: The FailoverTransport nested class FailoverTask has two ConnectionStateTrackers this keeps a dictionary which links the ConnectionId to the ConnectionState. The ConnectionState itself has a dictionary which links the transactionId to the TransactionState. The TranscationState tracks commands. BUT these commands are never freed up from the transaction state and stay there forever which will blow up the memory some time. I'm currently investigation how to fix this but must first properly understand the code. I opened up this issue in the hope that it will ring a bell for you guys. Daniel -- 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-433) Correctly rethrow exceptions without swallowing the stack trace
[
https://issues.apache.org/jira/browse/AMQNET-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13643365#comment-13643365
]
Daniel Marbach commented on AMQNET-433:
---
Thank you! I must say I have some issues with your formulated answer. I don't
see why you consider improving the product as a waste of time. But certainly I
can also go through the code and do it if your time is so precious!
Correctly rethrow exceptions without swallowing the stack trace
---
Key: AMQNET-433
URL: https://issues.apache.org/jira/browse/AMQNET-433
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Reporter: Daniel Marbach
Assignee: Jim Gomes
Priority: Trivial
Fix For: 1.6.0
When looking through the code I saw a lot of the following code snippets:
try
{
}
catch(AnyException ex)
{
// do something
throw ex;
}
This WILL rewrite the stack trace and is not considered best practice. I
suggest you change the appropriate places in the code to:
try
{
}
catch(AnyException ex)
{
// do something
throw;
}
--
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-405) Messages are not dequeued when using Two Phase Commit for DTC Transaction
[
https://issues.apache.org/jira/browse/AMQNET-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580461#comment-13580461
]
Daniel Marbach commented on AMQNET-405:
---
See also patch provided in https://issues.apache.org/jira/browse/AMQNET-413
which also fixes this problem
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
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();
[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-tabpanelfocusedCommentId=13579340#comment-13579340
]
Daniel Marbach commented on AMQNET-413:
---
Hy timothy, I wanted to get the tests to run so that we can provide a patch.
But it makes my head hurt! Could you please provide sample xml configurations
(for the base test class) and more detailed readme so that I can get the tests
to run. Without that I cannot provide anything...
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
]
Daniel Marbach updated AMQNET-413:
--
Attachment: AMQNET-413.patch
In the meantime until you guys respond to my issues regarding unit testing
infrastructure here is the changes which fixes the issue. Please review
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: 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-404) ActiveMQByteMessage Content accessing multiple times wipes the property
[
https://issues.apache.org/jira/browse/AMQNET-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558099#comment-13558099
]
Daniel Marbach commented on AMQNET-404:
---
Ok. Didn't know that. But this design is completely against the framework
design guidelines. Accessing a property multiple times should return the same
result.
ActiveMQByteMessage Content accessing multiple times wipes the property
---
Key: AMQNET-404
URL: https://issues.apache.org/jira/browse/AMQNET-404
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Affects Versions: 1.5.6
Reporter: Daniel Marbach
Assignee: Jim Gomes
Priority: Minor
If you have an IBytesMessage and for example do the following:
byte[] content = null;
if (message.Content!= null)
{
content = message.Content;
}
Accessing content the first time will return the correct data.
Accessing a second time the content property will return an empty byte array
which has the length of the data but all bytes are zero.
It is OK that the content property is evaluated lazily but it should not
return different data when accessing multiple times. So accessing the
property the first time should read the buffer and assign it to a field and
then always return that byte buffer.
--
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-404) ActiveMQByteMessage Content accessing multiple times wipes the property
Daniel Marbach created AMQNET-404:
-
Summary: ActiveMQByteMessage Content accessing multiple times
wipes the property
Key: AMQNET-404
URL: https://issues.apache.org/jira/browse/AMQNET-404
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Affects Versions: 1.5.6
Reporter: Daniel Marbach
Assignee: Jim Gomes
Priority: Minor
If you have an IBytesMessage and for example do the following:
byte[] content = null;
if (message.Content!= null)
{
content = message.Content;
}
Accessing content the first time will return the correct data.
Accessing a second time the content property will return an empty byte array
which has the length of the data but all bytes are zero.
It is OK that the content property is evaluated lazily but it should not return
different data when accessing multiple times. So accessing the property the
first time should read the buffer and assign it to a field and then always
return that byte buffer.
--
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
