apache / apache/pulsar-client-cpp

[Bug] [ARM] Partially acknowledged batches are not redelivered

未关闭
#424 6 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
主要语言
C++
星标
71
派生
90
平均合并
2 小时 33 分钟
30 天内合并 PR
3

描述

### Search before asking

- [X] I searched in the [issues](https://github.com/apache/pulsar-client-cpp/issues) and found nothing similar.

### Version

Debian GNU/Linux 10 (buster), aarch64 (but the executable is arm32), pulsar-client-cpp 3.3.0

### Minimal reproduce step

1. Send a batch of events to the Pulsar broker (in our reproduction, it is a batch size of 309).
2. Receive these messages (we're using `pulsar::Consumer::receive` in a loop), while continuously acknowledging them asynchronously (acknowledgements are done using `pulsar::Consumer::acknowledge(const MessageId &messageId)`, where `messageId` is `pulsar::Message::getMessageId`).
3. Terminate the program during the middle of receiving a batch (we're terminating after having received and acknowledged the 190/309 events from a batch).
4. Resume the program.

### What did you expect to see?

All of the events in the batch re-sent.

### What did you see instead?

None of the events in the batch, _including the ones never received_ are re-sent.

### Anything else?

- We log the result of the acknowledgement in the callback method, which shows us that the most we've acknowledged is the `190th` message in a batch.
- Exclusive subscription.
- Running it on Gravitron2/3 processors.
- We've used the same broker and test with an x86_64 Pulsar 3.3.0 Pulsar client, and we've had no issues (RHEL8).
- We can actively see missing messages - we are just sending consecutive numbers and logging them. We're missing exactly 119, the amount remaining in the batch that we've not fully acknowledged.
- We've tried not immediately terminating - i.e. we stop receiving messages but continue to process any callbacks, to validate that we're just not seeing 119 callbacks missing, and nothing.

### Are you willing to submit a PR?

- [ ] I'm willing to submit a PR!

贡献指南

打开贡献指南

调研方向

从使用 Message::getMessageId 的 Consumer::receive 循环和异步 Consumer::acknowledge 路径开始,然后在所述的 ARM 配置上重现 309 事件批次中断。完成的标准是:仅确认批次的一部分并重启后,批次中的所有事件(包括尚未接收的剩余事件)都会重新投递。

由索引模型根据 Issue 内容生成。

评估

技术栈
cpp
领域
distributed-systems
Issue 类型
缺陷
难度
4/5
预计耗时
3-5 天
活跃度
停滞
描述清晰度
基本清楚
新手友好度
35/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。