[
https://issues.apache.org/activemq/browse/AMQNET-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved AMQNET-176.
---------------------------------
Resolution: Fixed
Resolved in Trunk: Rev 830751
> 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.
