Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Sat, 20 Aug 2011 21:26:27 +0000 (UTC)
From: "Timothy Bish (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: 
 <1927047646.56070.1313875587180.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1571522942.36873.1313305227504.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (AMQ-3450) Acknowledging prefetched messages
 using client acknowledge mode
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Timothy Bish commented on AMQ-3450:
-----------------------------------

This is the expected behavior at present.  There's an open issue related to that AMQ-3158 which you can vote on, or better yet, dive in and see if you can come up with a patch to fix the issue.  

> 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