activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hariharan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-3450) Acknowledging prefetched messages using client acknowledge mode
Date Wed, 17 Aug 2011 03:56:33 GMT

    [ https://issues.apache.org/jira/browse/AMQ-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086110#comment-13086110
] 

Hariharan commented on AMQ-3450:
--------------------------------

But Tim, when enqueue count gives the number messages that were sent to the destination, then
 shouldn't the dequeue count give the number of messages that have been removed from the destination?


If I understood the count's right, then this is the only count which would reflect the messages
that have been ackd by the client(s) and removed by the broker, isn't it?
If not, can you please let me know if there is any other way I can find the equivalent of
dequeue count using admin query?

> Acknowledging prefetched messages using client acknowledge mode
> ---------------------------------------------------------------
>
>                 Key: AMQ-3450
>                 URL: https://issues.apache.org/jira/browse/AMQ-3450
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>            Reporter: Hariharan
>              Labels: broker
>         Attachments: my_client.pl
>
>
> We have a situation in front of us and its explained as below:
> 1. We have durable subscriber subscribed to a topic. 
> 2. This durable subscriber is a perl script which is run by a daemon.
> 3. The perl script uses stomp to connect to the broker.
> 4. The perl script wakes up every 5 mins, checks for messages in the topic and processes
them in a batch by pre-fetching the messages.
> 5. The subscriber uses a client acknowledgement and acknowledges only the last message
of the batch.
> 6. We are using AMQ 5.5 with kahaDB persistence.
> Now what we see is,
> 1. Even though the messages are processed in a batch and the last message is acknowledged
the inflight count does not come down.
> 2. Enqueue count, Dequeue count and Dispatch count do not match.
> 3. The journal files are not getting cleaned up.
> I do understand that the journal files would be cleaned up once the references to the
messages are lost or removed (i.e. the messages are consumed). But does it have to do anything
with the various count attributes I see on the topic?
> Also should I expect the inflight count to come down to 0 if client crashes and then
consumes all messages after come back live?
> I also see that dequeue count stays at 0 even when the dispatch count and the inflight
counts change. I believe dequeue count has got a direct relation with messages getting removed
from the topic.
> Please let me know if there could be any other reason that could cause the journal files
to stay back.
> Thank you
> Hari

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message