crossoverJie commented on issue #1504: URL: https://github.com/apache/pulsar-client-go/issues/1504#issuecomment-4514807845
Thanks for the proposal. I think adding `Pause()` / `Resume()` to the Go consumer makes sense and would close a useful parity gap with the Java client. A few details may need to be clarified before implementation: 1. `Pause()` should probably be documented as “stop issuing new flow permits”, not “stop receiving immediately”. The client may already have locally buffered messages, broker-dispatched messages in flight, or previously granted permits. So users may still observe messages from `Receive()` / `Chan()` after calling `Pause()` until those are drained. 2. Reconnect needs explicit handling. In the current Go implementation, the dispatcher sends initial permits when it receives a new connection event. If the consumer is paused, reconnect should not blindly send those initial permits. Otherwise a paused consumer can start receiving again after reconnect. 3. `EnableZeroQueueConsumer` should be covered. In zero-queue mode, `Receive()` itself triggers one permit. The proposal should define the expected behavior when paused, for example: `Receive(ctx)` blocks until `Resume()` or until the context is cancelled. 4. Regex consumers and dynamic topic discovery need to inherit the paused state. If a regex consumer is paused and later discovers/ subscribes to a new topic, the newly created internal consumer should also start paused. 5. `IsPaused()` should probably be defined at the top-level consumer as “whether `Pause()` was called more recently than `Resume()`”. Deriving it from all partition consumers may be ambiguous, especially with regex/multi-topic consumers and dynamically added partitions. 6. The subscription-type behavior should be documented a bit more broadly. For example, in `KeyShared` and `Failover`, pause does not change membership or trigger reassignment/failover because the consumer remains connected. It only affects flow permits. In `Shared`, dispatching should naturally move away from the paused consumer after its permits are exhausted. Overall, I support the API, but I think the proposal should make the exact semantics around permits, reconnect, zero-queue consumers, and dynamic consumers explicit. That would make the implementation easier to review and prevent surprising behavior. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
