I support this motivation. We should avoid any cases which might break the at-least-one delivery semantic from the user's perspective.
Thanks, Penghui On Thu, Aug 11, 2022 at 1:36 PM Michael Marshall <mmarsh...@apache.org> wrote: > Hi Pulsar Community, > > In Pulsar 2.5.0, the semantics for a message's redeliveryCount changed > at the request of this issue [0]. Please see the issue for relevant > context. > > In summary, the issue is whether a message that is neither positively > nor negatively acknowledged should get counted as "redelivered" when a > consumer disconnects from the broker. > > The issue asserts that because a message could lead to a fatal error > in the consumer application that could prevent negative > acknowledgement getting sent to the broker, every delivery of a > message should count towards the redeliveryCount. > > In my view, this edge case should not justify changing the > redeliveryCount semantics. It is the responsibility of the application > to handle all messages, even those that are malformed. > > My primary motivation for revisiting this design is to discuss one of > its consequences. After the change, messages that are only ever sent > to an application's receiverQueue are counted against the delivery > count used to determine whether a message ought to go to the DLQ > topic. Because the DLQ implementation uses the redeliveryCount to > determine when a message has been attempted "enough" times, there is a > chance that messages can get sent to the DLQ without ever having been > "received" by the consuming application. While this scenario is > unlikely, I think it introduces doubt into this feature's design > because it is possible for messages to get classified as dead letters > without delivery at least the maxRedeliverCount. > > Here is my PR to adopt the original behavior [1]. Please take a look. > > Thanks, > Michael > > [0] https://github.com/apache/pulsar/issues/5881 > [1] https://github.com/apache/pulsar/pull/17060 >
