The delivery semantics are a very succinct way to describe my concerns, thanks for your comment Penghui.
My only other question is whether we classify the behavior change as a regression that should be fixed in existing releases or if it should only be reverted for 2.12 and beyond. I propose it should get cherry picked to existing release branches because of the impacts to delivery semantics. Thanks, Michael On Sun, Aug 14, 2022 at 7:21 PM PengHui Li <peng...@apache.org> wrote: > 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 > > >
