Lari Hotari
09/27/2025, 1:09 PMArtur Jablonski
09/30/2025, 6:24 AMck_xnet
10/01/2025, 1:01 PMLari Hotari
10/02/2025, 4:05 AMFabri
10/03/2025, 8:38 PMPraveen Gopalan
10/06/2025, 6:37 AMzaryab
10/09/2025, 1:02 PMNicolas Belliard
10/15/2025, 2:18 PMdelayedDeliveryTrackerFactoryClassName.
We initially used InMemoryDelayedDeliveryTracker, (because we where using version 2.7 of pulsar) which caused acknowledged delayed messages to be reprocessed after a broker restart likely due to its state stored only in memory. Given our high message volume (millions), this behavior is problematic. A screenshot is available showing the lag escalation following a broker restart. We're generating delayed messages out of sequence, resulting in gaps within the acknowledged message stream. This causes non-contiguous ranges of messages to be marked as deleted or eligible for deletion. In our screenshot, the value of nonContiguousDeletedMessagesRanges is 16833.
To mitigate this following the upgrade of pulsar to the version 4.0.4, we updated the broker config to use org.apache.pulsar.broker.delayed.BucketDelayedDeliveryTrackerFactory, which should persist delayed delivery metadata to disk via BookKeeper ledger buckets.
However, after switching to the bucket-based tracker, we're still seeing the same behavior post-restart. A few observations and questions:
• I checked the pulsar_delayed_message_index_loaded metric and noticed that messages are still being loaded into memory, while pulsar_delayed_message_index_bucket_total remains at zero. Is this expected? Shouldn’t the bucket tracker be persisting and loading from disk?
• Are there additional broker settings required to fully enable bucket-based delayed delivery tracking? For example:
◦ Do we need to explicitly configure delayedDeliveryTrackerBucketSize or delayedDeliveryMaxNumBuckets?
◦ Is there any dependency on topic-level settings or namespace policies that could override the broker-level tracker configuration?
◦ Could other settings interfere with delayed message persistence?
Any insights or guidance would be greatly appreciated. Thanks for your help!benjamin99
10/17/2025, 3:01 AMJonatan Bien
10/21/2025, 7:14 PMMargaret Figura
10/22/2025, 4:00 PMprintln() or other work per message). Again, CPU usage is under 10% for all components, but I see the same small drops.
I started debugging and found Pulsar is dropping because the Netty connection's .isWritable() returns false and this causes Pulsar to immediately drop. This "Returns true if and only if the I/O thread will perform the requested write operation immediately", meaning there is room available in Netty's ChannelOutboundBuffer. I found that if I increase the Netty low/highWaterMarks, the drops go away, but it's not possible without a code change to Pulsar broker.
I'm looking for any suggestions on different configurations I can try. Thanks!!Vaibhav Swarnkar
10/25/2025, 7:26 PMKiryl Valkovich
10/26/2025, 7:42 PMAndrew
10/29/2025, 5:11 AMDavid K
10/29/2025, 12:47 PMJack Pham
10/29/2025, 5:41 PM..<subscription>-<consumerName>-DLQ) be as well, since it uses the consumer name in the producer’s name? Will consumer stop consuming message if this happen?
We are using Pulsar client 4.0.0 where producer name constructed as:
.producerName(String.format("%s-%s-%s-DLQ", this.topicName, this.subscription, this.consumerName))Romain
10/29/2025, 7:23 PMschemaValidationEnforced=true and isAllowAutoUpdateSchema=false (only under an approved process), so only admins can push schemas.
Here’s the issue: when a consumer is configured with a DeadLetterPolicy and a message fails too many times (or is negatively acknowledged repeatedly), the client will publish the message to a dead-letter topic (default name <topic>-<subscription>-DLQ) after the redelivery threshold.
That topic doesn’t necessarily exist ahead of time (unless created before), so when it’s first used it may trigger topic creation and/or schema registration. Because our namespace forbids auto schema updates and enforces schemas, this can fail - the consumer isn’t authorized to register the schema for the DLQ topic.
To work around this, we’re creating a separate namespace (e.g., <namespace>-dlq) where:
• isAllowAutoUpdateSchema=true
• schemaValidationEnforced=false
• so consumers can safely publish DLQ messages without schema conflicts.
Is this the recommended approach? Is there a cleaner way to allow DLQ schema creation while keeping production namespaces locked down?
Any official guidance or community best practices would be really appreciated 🙏
Thanks!Francesco Animali
10/30/2025, 8:52 AMChaitanya Gudipati
11/05/2025, 3:48 PMJack Pham
11/05/2025, 11:11 PMTomek Zmijowski
11/06/2025, 9:46 PMPublish ordering guarantee
Consumer ordering guarantee
Incoming replicator ordering guarantee
Outgoing replicator ordering guarantee with the topic unavailability tradeoff
Auto resource creation (tenant, namespace, partitioned-topic, subscriptions) in a green cluster
Auto topic deletion after migration successfully completed for a topic
Enable migration at cluster level or per namespace level
Stats to show topic's migration state
But the thing is that due to missing configuration steps, it's hard to test this feature. Can someone explain how to start with that?Ujjain Bana
11/10/2025, 1:57 PMbhasvij
11/11/2025, 2:29 PMNithin Subbaraj
11/12/2025, 10:47 AMLari Hotari
11/17/2025, 8:58 AMAlexandre Burgoni
11/17/2025, 9:27 AM504 Gateway Timeout from pulsar clients in a production cluster ? We are currently experiencing timeout of proxies from time to time on multiple clusters with a HTTP 504, exception message is SSL BAD PACKET LENGTH. It looks like an issue between proxy - broker connection pool, but cannot yet prove it. We're running 4.1.0
We have to reboot proxies to fix the issue for nowAlexander Brown
11/17/2025, 7:03 PMDavid K
11/17/2025, 7:45 PMBen Hirschberg
11/17/2025, 11:13 PMsensor_id, but I don’t want long-lived key to consumer stickiness. Instead, I’m trying to achieve this logic:
If no consumer is currently processing, then the next message for that sensor should be assigned to the next available consumer (round-robin or least-loaded).sensor_id = X
All while preserving ordering and ensuring no two consumers ever process the same key concurrently.
KeyShared ensures ordering and exclusivity, but it uses stable key-range hashing, so a key stays with one consumer until that consumer dies.
Is there any Pulsar pattern, config, or upcoming feature that supports dynamic per-message key assignment instead of sticky key-range ownership?
Or is this fundamentally outside Pulsar’s delivery semantics?
Thanks! 🙏Ben Hirschberg
11/18/2025, 6:12 AMKeyShare option, since we do want messages to be processed in order per Key (this is something our design requires)