When I saw xiangying reply, I also remembered PIP-415. https://github.com/apache/pulsar/pull/24220
At present, admin-api in PIP-423 can actually add a new parameter "index". If the user does not set ledgerId and entryId, he can also set "index". Thanks, sinan SiNan Liu <liusinan1...@gmail.com>于2025年6月10日 周二11:03写道： > 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 >> > > > > > > >> > > > > > >> > > > >> > > >> >
