Permits in Pulsar and related systems are used for flow control, limiting how many messages a consumer can receive before it must acknowledge or request more. The broker tracks available permits for each consumer; when a consumer receives messages, its available permits decrease, and when it processes or acknowledges messages, it can request more permits from the broker to continue receiving data. This mechanism prevents consumers from being overwhelmed and helps manage backpressure in the system. According to
Consumer.java, permits are incremented or decremented as messages are delivered and acknowledged.
Permits are also used in client libraries (e.g., Go, Java, Rust) to synchronize message flow and avoid resource exhaustion or message loss. Issues can arise if permits are not managed correctly, such as consumers getting stuck or negative permit counts, as discussed in
pulsar-client-go issue #1180 and
pulsar issue #24418.
Would you like more detail on how permits are implemented or managed in a specific client or scenario?
Sources:
-
Consumer.java
-
pulsar-client-go issue #1180
-
pulsar issue #24418 👍 1 button 👎 0 button 💡
Hint: Mention
@RunLLM in the thread for followups.