Messages received by a transactional session are not redelivered when the
session dies before being commited.
-------------------------------------------------------------------------------------------------------------
Key: AMQNET-176
URL: https://issues.apache.org/activemq/browse/AMQNET-176
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ Client
Environment: .NET 2.0 on Windows XP
Reporter: Daniel Ellis
Assignee: Jim Gomes
In our testing we have discovered that messages are not redelivered as expected
when we are using a transactional session. The test goes as follows:-
1. Create a connection and a transactional session.
2. Create a queue consumer, add a listener and start the connection.
3. Add a message to the queue, the message will arrive on the consumer.
4. Kill the session (either dispose of the session and connection, or just
kill the process)
5. Perform steps 1 & 2 again.
Note that the message is not redelivered.
We expect the message to be redelivered because the transaction was never
committed. Looking at the Queues page on the web admin, you can see the queue
count is still 1. So the message is still on the broker.
To diagnose whether this is an NMS issue or an ActiveMQ issue, I created a Java
application to test this issue using JMS.
The resulting behaviour is as expected when using JMS. After the message is
received, I can either cleanly dispose the session, or kill the application,
and the message will be redelivered next time you start the app.
I was a little confused as to why the message did not get redelivered, in the
example where I simply kill the process. I would expect the broker to handle
NMS and JMS clients the same, as the TCP connection would simply be terminated.
I then noticed a difference between NMS and JMS, when looking in the web admin.
When a message arrives on a JMS client the queue count shows 1, and clicking
on the queue shows the message still on the queue. When a message arrives on
an NMS client, the queue count goes to 1, but clicking on the queue shows no
messages.
Clearly, there is a difference between how JMS and NMS handle an incoming
message on a transactional session. Could it be that NMS is sending an ack for
each message when it shouldn't?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
