使用客户端确认模式确认预取消息
我们面前有一种情况，其解释如下：
- 我们有持久订阅者订阅了一个主题。这个持久订阅者是一个由守护进程运行的 perl 脚本。
- Perl 脚本使用 stomp 连接到代理。
- Perl 脚本每 5 分钟唤醒一次，检查主题中的消息并通过预取消息来批量处理它们。
- 订阅者使用客户端确认并仅确认该批次的最后一条消息。
- 我们使用 AMQ 5.5 和 kahaDB 持久性。
现在我们看到的是，
- 即使消息是批量处理的并且最后一条消息被确认，飞行计数也不会下降。
- 入队计数、出队计数和调度计数不匹配。
- 日志文件没有被清理。
我确实了解，一旦对消息的引用丢失或删除（即消息被消耗），日志文件就会被清理。但它与我在该主题中看到的各种计数属性有什么关系吗？
另外，如果客户端崩溃，然后在返回后消耗所有消息，我是否应该期望飞行计数降至 0？
如果有任何其他原因可能导致日志文件保留，请告诉我。
谢谢哈里
We have a situation in front of us and its explained as below:
- We have durable subscriber subscribed to a topic. This durable subscriber is a perl script which is run by a daemon.
- The perl script uses stomp to connect to the broker.
- 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.
- The subscriber uses a client acknowledgement and acknowledges only the last message of the batch.
- We are using AMQ 5.5 with kahaDB persistence.
Now what we see is,
- Even though the messages are processed in a batch and the last message is acknowledged the inflight count does not come down.
- Enqueue count, Dequeue count and Dispatch count do not match.
- 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?
Please let me know if there could be any other reason that could cause the journal files to stay back.
Thank you
Hari
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
实际上，我在发送确认后立即断开连接。
在断开连接之前等待确认的接收解决了该问题。
Actually I was disconnecting immediately after sending the ack.
Waiting for ack's receipt before disconnecting solved the issue.