Hi Michael, I agree with cherry-picking to release branches. And should be highlighted in the release note.
Thanks, Penghui On Thu, Aug 18, 2022 at 12:14 PM Michael Marshall <mmarsh...@apache.org> wrote: > 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 > > > > > >
