activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From SuoNayi <suonayi2...@163.com>
Subject Reply:Re: Reply:Re: What will happen if consumer uses the client acknowledge model but no further explicit acknowledges are made?
Date Wed, 26 Dec 2012 01:47:46 GMT
Merry Christmas!
Chirs, you can see the dispatched queue size in the page by viewing 
the active consumers of some queue on the web console.
There will be one dispatched list inside every subscriber in the broker.
That list is used to track the messages that are dispatched to consumers
but are not acked by them.When consumers ack messages these messages
will be removed from the dispatched list.So the dispatched queue size reflects
how many messages are dispatched to the consumers while not acked.
I believe the dispatched queue size is derived from the official, not my 
personal saying.
My purpose of this post is to make sure the consequence for my extreme use 
case and it's not intended to discuss the solutions.


Thanks,
SuoNayi

At 2012-12-26 01:07:45,chris.odom@mediadriver.com wrote:
>SuoNayi,
>   I guess what I was trying to elude to was that there is no dispatch 
>queue per say but just a dispatch count. The queue that the message was 
>dispatch from is the queue for the message, and the metrics are a 
>representation of what the broker has done with those messages in the 
>queue. With that said you are correct in the fact that if consumers are 
>not acknowledging messages the messages will not get dequeued and the 
>Broker will maintain the message in the queue causing the memory needed 
>for the messages to not be released. There are many ways of handling 
>these scenarios from expiring messages to auto acknowledging.
>
>
>On 2012-12-23 19:57, SuoNayi wrote:
>> Thanks chris, in fact I know what these metrics mean.
>> Here I just want to make sure the consequence of my use case where
>> my consumer only receives messages but not ack them at all(via the
>> client acknowledge model).Because the broker need track the messages
>> that are dispatched to the consumer and not acked by the consumer all
>> the time so the dispatched queue size keeps increasing.
>> When lots of messages(supposing there are many pending messages
>> for dispatch) are dispatched to the consumer the memory consumption
>> in the broker will exceed the memory limit of the queue at last, the
>> dispatch
>> job will pause for waiting for available memory space.
>>
>>
>> Hope someone can correct my judgement.
>> Thanks,
>> SuoNayi
>>
>> At 2012-12-23 23:46:16,chris.odom@mediadriver.com wrote:
>>>
>>>SuoNayi
>>>    Queue's only keep one copy of any message at any given time, that 
>>> I
>>>am aware of. What you are seeing the web console are metrics that the
>>>Broker maintains about the Queue. Messages arrive to a Queue the 
>>> Enqueue
>>>count increments. A Consumer reads a message from the Queue the 
>>> Dispatch
>>>count increments. The Consumer acknowledges receipt of the message 
>>> the
>>>Dequeue count increments. These are just numbers that correspond to 
>>> the
>>>actions that the Broker has taken for a message. Hopefully these help
>>>explain what it is you are seeing.
>>>
>>>On 2012-12-23 08:40, SuoNayi wrote:
>>>> Hi all,
>>>> I just want to make sure what will happen if my consumer uses the
>>>> client acknowledge model
>>>> but no further explicit acknowledges are made?According to my
>>>> observation,when producers are keeping
>>>> sending messages to the queue,the dispatched queue size for my
>>>> consumer (on the web console)
>>>> keeps increasing.
>>>> I assume that with the increase of the dispatched queue size, more
>>>> and more messages will be
>>>> loaded into the dispatched queue for the subscription in the broker
>>>> and more memory is taken from the SystemUsage.
>>>> When the memory limit is exceed,the dispatch messages to the 
>>>> consumer
>>>> will pause for available memory space.
>>>> If the memory usage is not handled properly, OOM will be thrown.
>>>>
>>>>
>>>> Please correct me if I'm wrong.
>>>>
>>>>
>>>> Thanks,
>>>> SuoNayi
>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message