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 > > > > > > > > > > > > > > > >
