lhotari commented on code in PR #24625: URL: https://github.com/apache/pulsar/pull/24625#discussion_r2334848575
########## pip/pip-437.md: ########## @@ -0,0 +1,129 @@ +# PIP-437: Granular and Fixed-Delay Policies for Message Delivery + +# Background +Pulsar's delayed delivery feature allows producers to schedule messages to be delivered at a future time. To provide administrative control and prevent abuse, **PIP-315** introduced a `maxDeliveryDelayInMillis` policy. +While this provides an important safeguard by setting an *upper bound*, it does not address all administrative needs. There is currently no way to enforce a *specific, non-overridable* delay for all messages on a topic. + +# Motivation + +### The Limitation: +Pulsar's delayed message delivery relies on tracking individual messages until their delivery time. This tracking state is persisted as part of the subscription's cursor metadata, +which records gaps or "holes" for unacknowledged messages. The Pulsar Managed Ledger has a hard limit on the number of disjoint unacknowledged ranges it can persist for a cursor, +configured by `managedLedgerMaxUnackedRangesToPersist` (defaulting to 10,000). +A large volume of messages with widely varying delivery times can easily exhaust this capacity with each delayed message creating a separate unacknowledged hole. + +### The Impact: Upon restart, the broker's only source of truth is the last persisted cursor position. +Once the `managedLedgerMaxUnackedRangesToPersist` limit is breached, the broker stops persisting the cursor's state and maintains it only in memory. This in-memory state is volatile and is completely lost if the broker restarts for any reason. +Upon restart, the broker's only source of truth is the last successfully persisted cursor position. This position does not account for the lost tracking information, forcing the broker to re-dispatch all messages that were being tracked in memory. +This results in significant and difficult-to-predict message duplication for downstream consumers. + +The lack of administrative controls on message delivery delays introduces critical risks to cluster stability and data integrity. +This proposal aims to provide granular control at the topic and namespace levels to add a new fixed delay delivery configuration: + +1. **Prevent Message Duplication:** By forcing all messages on a topic to have the exact same delay,it prevents the delayed message tracker from becoming overwhelmed and eliminates the risk of message duplication upon broker restart, leading to a more stable and predictable system. +2. **Enforcing Compliance and Business Rules:** Certain workflows may require certain control that require the enforcement at the broker level +3. **Simplifying Producer Configuration:** By setting a fixed delay on the topic, the responsibility for managing the delay logic is shifted from the client to the broker, reducing the risk of client-side misconfiguration. + +# Goals +## In Scope +- Introduce a new `fixed-delivery-delay` policy, configurable at the namespace and topic levels, to enforce a mandatory delivery delay. +- Enhance the existing `/delayedDelivery` admin API endpoints and `pulsar-admin` commands to manage both the existing `maxDeliveryDelayInMillis` and the new `fixedDeliveryDelayInMillis` policies within the same policy group. +- Ensure the `fixed-delivery-delay` policy takes precedence over any client-specified delay and the existing `max-delivery-delay` policy. + +# High Level Design +This proposal will enhance the existing `DelayedDeliveryPolicies` object to include a new `fixedDeliveryDelayInMillis` field. +This new policy will follow Pulsar's standard hierarchical model, allowing it to be set at the namespace level and overridden at the topic level. +The core logic will be implemented with the following precedence: + +1. **If `fixed-delivery-delay` is set:** The broker will ignore any `deliverAt` time sent by the producer and will override it by calculating `publish_time + fixed_delay`. The `max-delivery-delay` policy is ignored. Review Comment: This has been addressed with the `pulsar.broker.topic.messages.fixed.delay.overridden` counter for monitoring. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@pulsar.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
