You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Hariharan (JIRA)" <ji...@apache.org> on 2011/08/14 09:00:27 UTC
[jira] [Created] (AMQ-3450) Acknowledging prefetched messages using
client acknowledge mode
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
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
[jira] [Commented] (AMQ-3450) Acknowledging prefetched messages
using client acknowledge mode
Posted by "Hariharan (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (AMQ-3450) Acknowledging prefetched messages
using client acknowledge mode
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085363#comment-13085363 ]
Timothy Bish commented on AMQ-3450:
-----------------------------------
Your client Id doesn't match your subscription name.
https://activemq.apache.org/stomp.html
> 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
[jira] [Updated] (AMQ-3450) Acknowledging prefetched messages using
client acknowledge mode
Posted by "Hariharan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hariharan updated AMQ-3450:
---------------------------
Attachment: my_client.pl
> 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
[jira] [Resolved] (AMQ-3450) Acknowledging prefetched messages
using client acknowledge mode
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Bish resolved AMQ-3450.
-------------------------------
Resolution: Not A Problem
Fixed by adding a wait for receipt on the last message sent so that all messages get processed before the socket is broken.
> 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
[jira] [Updated] (AMQ-3450) Acknowledging prefetched messages using
client acknowledge mode
Posted by "Hariharan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hariharan updated AMQ-3450:
---------------------------
Attachment: (was: my_client.pl)
> 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
[jira] [Commented] (AMQ-3450) Acknowledging prefetched messages
using client acknowledge mode
Posted by "Hariharan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13084841#comment-13084841 ]
Hariharan commented on AMQ-3450:
--------------------------------
I will try to get a sample ready asap.
Right now we only do acknowledge like this :
$stomp_obj->ack({frame => $last_msg_frame});
$stomp_obj->disconnect();
How exactly do I send a receipt request in the ack message? I will try this as well.
> 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
>
> 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
[jira] [Commented] (AMQ-3450) Acknowledging prefetched messages
using client acknowledge mode
Posted by "Hariharan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085554#comment-13085554 ]
Hariharan commented on AMQ-3450:
--------------------------------
Yup had tried that too, even that did not work. Dispatch count changes but dequeue count still down at 0.
Attaching the modified client script.
> 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
[jira] [Commented] (AMQ-3450) Acknowledging prefetched messages
using client acknowledge mode
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13084839#comment-13084839 ]
Timothy Bish commented on AMQ-3450:
-----------------------------------
Do you have a sample that can demonstrate the issue? Do you send a receipt request in the ack message and wait for that to arrive before closing your connection?
> 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
>
> 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
[jira] [Commented] (AMQ-3450) Acknowledging prefetched messages
using client acknowledge mode
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085917#comment-13085917 ]
Timothy Bish commented on AMQ-3450:
-----------------------------------
This is correct, the dequeue count should be zero for topic destinations.
> 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
[jira] [Commented] (AMQ-3450) Acknowledging prefetched messages
using client acknowledge mode
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13084844#comment-13084844 ]
Timothy Bish commented on AMQ-3450:
-----------------------------------
Give the Stomp 1.0 spec a read through, specifically the section called Standard Headers.
http://stomp.github.com/stomp-specification-1.0.html
> 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
>
> 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
[jira] [Updated] (AMQ-3450) Acknowledging prefetched messages using
client acknowledge mode
Posted by "Hariharan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hariharan updated AMQ-3450:
---------------------------
Attachment: my_client.pl.pl
Client listener file.
> 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
>
> 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
[jira] [Updated] (AMQ-3450) Acknowledging prefetched messages using
client acknowledge mode
Posted by "Hariharan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hariharan updated AMQ-3450:
---------------------------
Attachment: (was: my_client.pl.pl)
> 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
>
> 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
[jira] [Commented] (AMQ-3450) Acknowledging prefetched messages
using client acknowledge mode
Posted by "Hariharan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085133#comment-13085133 ]
Hariharan commented on AMQ-3450:
--------------------------------
Thanks Tim. That was very helpful.
Waiting for ack receipt before disconnecting solved the issue.
However, even after sending the ack, the dequeue count never changes. Is this is a known issue?
I have attached my client code for your reference.
Once again thanks for helping me solve the problem.
> 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
[jira] [Updated] (AMQ-3450) Acknowledging prefetched messages using
client acknowledge mode
Posted by "Hariharan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hariharan updated AMQ-3450:
---------------------------
Attachment: my_client.pl
Client listener script.
> 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
[jira] [Commented] (AMQ-3450) Acknowledging prefetched messages
using client acknowledge mode
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ 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