Dear Pulsar Community, I would like to initiate a discussion regarding the optimization of the acktimeout mechanism on the client side. As we all know, the Pulsar consumer has a configuration for ack timeout that automatically redelivers unacknowledged messages after a certain period. The workflow is approximately as follows:
1. Record a message when it is received. 2. Remove the message from the record when the consumer begins to acknowledge it. 3. A timed task checks whether the messages from the record have reached the ack timeout and triggers redelivery for those messages. This workflow has a potential shortcoming: it does not wait for the ack response before removing the message from the record. If an ack request is lost during transmission to the broker - due to issues with proxy processing or buffer overflow after reaching the broker, for instance - then the ack timeout will not be resent, leading to an ack hole. While this situation is quite extreme and the likelihood of occurrence is extremely low, it is nonetheless a possibility. Another, more common scenario is when the broker fails to process or persist the ack request. In such cases, users who are highly sensitive to ack holes may prefer the message to be removed only after receiving the ack response. Perhaps we could add a parameter to the acktimeout to determine whether to wait for the ack response before removing the message. I am interested in hearing your thoughts on this issue and look forward to your responses and valuable suggestions. Best Regards, Xiangying
