Sounds like it is working as intended if I understand the usage you are
saying is happening. The client will refill the link credit in this
case every time a message is either read via (receive, receiver(timed)
or receiveNoWait) or when a message is handed off to an async consumer.
This happens because you've asked for a *prefetch* of one so the client
is instructing the broker to do just that. If you want only one message
to be dispatched to the client at a time then you want prefetch of zero
and then use the receive methods to pull a message from the broker on
demand.
On 12/03/2016 05:12 PM, Patrick Vansevenant wrote:
I'm talking about queues with a low message volume and high processing time.
In such a setup is it important that messages are not "heaping up" in the
dispatch queue.
The queueprefetch must be one in order to keep it workable.
I have done some tests with an ActiveMQ 5.14.1 broker and an AMQP consumer
with a
brokerURL configured with a queuePrefetch of one
(jms.prefetchPolicy.queuePrefetch=1).
I have the impression that the queuePrefetch becomes two during the period
that a message
is received and the time the acknowledgement is sent (clientacknowlegde
mode).
The consumer details in the ActiveMQ Web Console tells me that the
"Dispatched Queue"
contains two messages what should maximum be one with a defined
queuePrefetch of one.
Is it possible that the queuePrefetch doesn't work reliable in ActiveMQ
5.14.1 with an AMQP client ?
Patrick
--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/
