We just need to broaden the scope of the current PIP and rename the admin API to acknowledge-message.
The admin API as implemented in the PIP can already acknowledge any message. We'll simply mention in the documentation that this is how delayed messages can be effectively cancelled. Thanks, sinan xiangying meng <xiangy...@apache.org>于2025年6月10日 周二10:48写道： > I agree with Lari's point. We should provide an admin tool to help > users cancel a message, including delayed messages or regular > messages, as a best-effort operation. > > Additionally, if you have any customized requirements, such as a new > set of APIs for delayed messages—which may include an API for > canceling delayed messages—you can implement your idea in the > contributor repository [0]. > > [0] - https://github.com/apache/pulsar-java-contrib > > On Mon, Jun 9, 2025 at 9:22 PM Lari Hotari <lhot...@apache.org> wrote: > > > > Good work, Sinan. > > > > I'm just wondering if the operation in the admin API should be directly > about acknowledging the message instead of having a specific operation for > cancelling a delayed message. > > There might be a useful to "cancel" an individual message in a backlog > where delayed messaging isn't used at all with the same reasons as you have > stated for cancelling delayed messages. The operation could possibly > provide some best efforts based response whether this message has already > been sent out to consumers for delivery and whether the message was already > acknowledged. > > > > It would be great to have some comments from other community members as > well. > > > > -Lari > > > > On 2025/06/08 05:47:27 SiNan Liu wrote: > > > The document has been updated, we will implement the delayed message > > > cancellation function through acknowledge message. > > > > > > The configuration that needs attention regarding the message > > > "acknowledgment hole" is also reflected in the documentation. > > > > > > https://github.com/apache/pulsar/pull/24370 > > > > > > > > > Thanks, > > > sinan > > > > > > > > > Lari Hotari <lhot...@apache.org> 于2025年6月6日周五 19:54写道： > > > > > > > Sounds good to me. > > > > > > > > One consideration related to message acknowledgements is that there > > > > are currently relatively low limits to how many acknowledgements can > > > > be persisted. > > > > > > > > Some details in the discussion > > > > https://github.com/apache/pulsar/discussions/23990 > > > > > > > > There are configurable values > > > > managedLedgerMaxUnackedRangesToPersistInMetadataStore, > > > > managedLedgerPersistIndividualAckAsLongArray, > > > > managedLedgerMaxUnackedRangesToPersist and > > > > managedCursorInfoCompressionType to allow storing increasing the > > > > limits without exceeding ZooKeeper's maximum ZNode size configured in > > > > Pulsar (-Djute.maxbuffer=10485760). > > > > > > > > One detail is that managedLedgerPersistIndividualAckAsLongArray is > > > > currently missing from broker.conf. It's only in > > > > > > > > > pulsar-broker-common/src/main/java/org/apache/pulsar/broker/ServiceConfiguration.java > > > > . Configuring maxBatchDeletedIndexToPersist was completely missing. > > > > That's addressed in https://github.com/apache/pulsar/pull/24392 > > > > The managedCursorInfoCompressionType setting is currently missing > from > > > > broker.conf, that's addressed by > > > > https://github.com/apache/pulsar/pull/24391 > > > > PRs https://github.com/apache/pulsar/pull/24392 and > > > > https://github.com/apache/pulsar/pull/24391 also contain better > > > > documentation for the settings. > > > > We should also reconsider the default values for the various settings > > > > in Pulsar 4.1, for example, it would be useful to enable compression > > > > by default. > > > > > > > > -Lari > > > > > > > > On Fri, 6 Jun 2025 at 05:00, SiNan Liu <liusinan1...@gmail.com> > wrote: > > > > > > > > > > Yes, I'm also re-evaluating the current implementation. > > > > > > > > > > I believe that implementing it directly via message acknowledgment > would > > > > be > > > > > better, and I've been testing this approach over the past couple > of days. > > > > > > > > > > The current PIP modifies the internals of > BucketDelayedDeliveryTracker, > > > > and > > > > > this solution isn't as good as the message acknowledgment method. > > > > > > > > > > Later, I will change this PIP's implementation to use message > > > > > acknowledgment, and the current approach will become an alternative > > > > > solution. > > > > > > > > > > > > > > > Thanks, > > > > > sinan > > > > > > > > > > > > > > > Lari Hotari <lhot...@apache.org>于2025年6月5日 周四19:56写道： > > > > > > > > > > > Thanks for making the proposal and putting a significant effort > in > > > > > > preparing it. > > > > > > > > > > > > Would it be possible to consider an alternative solution where > delayed > > > > > > messages > > > > > > could be cancelled by acknowledging the messages? > > > > > > > > > > > > The admin API doesn't current contain an endpoint for > acknowledging a > > > > > > message, but I don't see a reason why that couldn't be > introduced. > > > > > > > > > > > > Any thoughts about this? > > > > > > > > > > > > -Lari > > > > > > > > > > > > On 2025/06/01 13:16:43 SiNan Liu wrote: > > > > > > > Hi all > > > > > > > > > > > > > > I want to start a discussion on > > > > > > > PIP-423: Add Support for Cancelling Individual Delayed Messages > > > > > > > Proposal link: https://github.com/apache/pulsar/pull/24370 > > > > > > > > > > > > > > I'm looking forward to hearing from you. > > > > > > > > > > > > > > Thanks, > > > > > > > sinan > > > > > > > > > > > > > > > > > > > > >
