You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by bryand <br...@bldixon.net> on 2018/02/13 18:21:55 UTC
Stopping JMS Connection with unprocessed prefetched messages
results in message moved to DLQ
I'm using qpid-broker-j-7.0.1, qpid-jms-amqp-0-x-6.3.0 and JDK 1.8.
We have a Java app that using using a JMS MessageListener to consume message
from a Queue. Occasionally we want to stop message consumption on the
Listener and then restart it. To stop message consumption I simply call the
.stop() method on the JMS Connection interface (I've tried calling .close()
on the JMS Session interface and it has the same undesired results). The
issue I keep running into with qpid is that any prefetched messages
retrieved by the session (and not committed yet) are getting moved to the
DLQ (Alternate Binding) when I call the connection.stop() method. The
expected behavior is that those prefetched messages would be left on the
source queue the MessageListener is consuming so that when we restart
message consumption its all ready to go for that source queue. I am also
utilizing local JMS transactions and doing a commit after consuming each
message - another reason I would expect the unprocessed prefetched messages
to be persisted on the source queue when the connection is stopped.
I have attached the source code for a little test app that will produced the
unexpected results. I also have a log file from a test run and a screen
shot of how I've defined the source queue (where you can see I have an
Alternate Binding defined - that is the DLQ the messages are getting moved
to when the connection is stopped.
TestTxnListener.java
<http://qpid.2158936.n2.nabble.com/file/t396334/TestTxnListener.java>
TxnListener.java
<http://qpid.2158936.n2.nabble.com/file/t396334/TxnListener.java>
AppUtils.java <http://qpid.2158936.n2.nabble.com/file/t396334/AppUtils.java>
output.log <http://qpid.2158936.n2.nabble.com/file/t396334/output.log>
queue-def.png <http://qpid.2158936.n2.nabble.com/file/t396334/queue-def.png>
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Stopping JMS Connection with unprocessed prefetched messages
results in message moved to DLQ
Posted by Keith W <ke...@gmail.com>.
On 14 February 2018 at 09:59, Keith W <ke...@gmail.com> 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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Stopping JMS Connection with unprocessed prefetched messages
results in message moved to DLQ
Posted by Keith W <ke...@gmail.com>.
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Stopping JMS Connection with unprocessed prefetched messages
results in message moved to DLQ
Posted by bryand <br...@bldixon.net>.
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Stopping JMS Connection with unprocessed prefetched messages
results in message moved to DLQ
Posted by bryand <br...@bldixon.net>.
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org