[
https://issues.apache.org/activemq/browse/AMQNET-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=54876#action_54876
]
Mark Gellings commented on AMQNET-176:
--------------------------------------
I can also confirm this is a problem. When we restart a consumer there are
many times a message gets stuck in the queue at a redelivered state. It does
not get redelivered to another consumer or when a single consumer starts back
up. It doesn't matter what the max redelivery count is set at, 5, 10, 5000, if
the consumer stops the message ceases to be redelivered.
This seems like a big problem with transactional acknowledgement mode. This
requires manual intervention to get the stuck message to be processed again
essentially by having to recreate it.
If we can do anything to help with this issue let us know. We can provide a
test case as well but looks like Daniel did a good job with that!
> 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
> Affects Versions: 1.1.0
> Environment: .NET 2.0 on Windows XP
> Reporter: Daniel Ellis
> Assignee: Timothy Bish
> Fix For: 1.2.0
>
> Attachments: ActiveMQ-Test.zip, Message to JMS transactional
> session.pcap, Message to NMS transactional session.pcap
>
>
> 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.
