Re: Stopping JMS Connection with unprocessed prefetched messages results in message moved to DLQ
On 14 February 2018 at 09:59, Keith W wrote: > Hi Bryan > > >> So that brings me to the potential bug. I found that when using the JMS >> QueueBrowser it actually increments the Delivery Count for a message >> everytime it is browsed. That is why most of my source messages had a >> Delivery Count > 0. This doesn't seem right - a read-only Queue Browse >> action shouldn't increment the Delivery Count if that same count is used to >> determine if the message should be moved to the Alternate Binding (DLQ) >> should it? > > Yes, that's a defect. Thanks for reporting. From my initial testing > this morning the defect affects only queue browsers with the AMQP 0-10 > implementation (AMQP 0-8..0-91 and AMQP 1.0 are not affected). The > delivery count for messages delivered to browser gets incremented. > For the message to be erroneously rerouted to a DLQ you would need a > normal consumer on the queue too. It would need to 'release' the > message for delivery elsewhere (e.g. a rollback or abnormal > disconnection). > > From an initial glance, the fix looks straightforward so I would hope > we could include this in a 7.0.2. Raised as: https://issues.apache.org/jira/browse/QPID-8098 - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Stopping JMS Connection with unprocessed prefetched messages results in message moved to DLQ
Hi Bryan Yes, that's a defect. Thanks for reporting. From my initial > So that brings me to the potential bug. I found that when using the JMS > QueueBrowser it actually increments the Delivery Count for a message > everytime it is browsed. That is why most of my source messages had a > Delivery Count > 0. This doesn't seem right - a read-only Queue Browse > action shouldn't increment the Delivery Count if that same count is used to > determine if the message should be moved to the Alternate Binding (DLQ) > should it? Yes, that's a defect. Thanks for reporting. From my initial testing this morning the defect affects only queue browsers with the AMQP 0-10 implementation (AMQP 0-8..0-91 and AMQP 1.0 are not affected). The delivery count for messages delivered to browser gets incremented. For the message to be erroneously rerouted to a DLQ you would need a normal consumer on the queue too. It would need to 'release' the message for delivery elsewhere (e.g. a rollback or abnormal disconnection). >From an initial glance, the fix looks straightforward so I would hope we could include this in a 7.0.2. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Stopping JMS Connection with unprocessed prefetched messages results in message moved to DLQ
I think I found why this behavior was occurring but I think I might have uncovered a bug with JMQ queue browsing... I tested with another source queue and there were no messages were being moved to the DLQ for that queue - the stayed on the source queue after the connection was closed and that is the behavior I was expecting. What I found was the messages on the first queue I was consuming had a Delivery Count > 5 so I'm assuming that when the connection was closed they went to the DLQ because I had a Maximum Delivery Retries of 5 configured. The second queue I used for consumption all had messages with a Delivery Count of 0. So that brings me to the potential bug. I found that when using the JMS QueueBrowser it actually increments the Delivery Count for a message everytime it is browsed. That is why most of my source messages had a Delivery Count > 0. This doesn't seem right - a read-only Queue Browse action shouldn't increment the Delivery Count if that same count is used to determine if the message should be moved to the Alternate Binding (DLQ) should it? -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Stopping JMS Connection with unprocessed prefetched messages results in message moved to DLQ
I just ran another test where I set the url to have a maxprefetch of 0: String brokerUrl = "amqp:///spgqpiddev?maxprefetch='0'&brokerlist='tcp://spgappdevmutil:5672'"; And it still ended up moving 2 messages to the DLQ after the connection was stopped. I'm really confused about this behavior. -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
