Yes, that's an excellent point. While the initial motivation for this PIP was to cancel delayed messages, the implementation is fundamentally a single-message acknowledgement. We can then leverage this function to achieve the goal of cancellation.
Comparison to the existing skip-messages admin API. This new feature is conceptually similar but offers more fine-grained control. While skip-messagesoperates on a number of messages for a subscription, this proposal allows targeting a specific message via its MessageId. https://pulsar.apache.org/docs/4.0.x/admin-api-topics/#skip-messages Given this, I agree that renaming the API to acknowledge-message is the right path forward. I hope to get more discussion. Thanks, sinan Lari Hotari <lhot...@apache.org>于2025年6月9日 周一21:22写道： > 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 > > > > > > > > > > > > > > > > >
