nodece commented on issue #1496: URL: https://github.com/apache/pulsar-client-go/issues/1496#issuecomment-4517108954
Thanks for the suggestion. After analyzing the `batchReceive` implementation in the Java client, we found that it is essentially a **client-side message accumulation wrapper** — it drains messages from the internal `incomingMessages` queue into a container based on a `BatchReceivePolicy` (maxNumMessages / maxNumBytes / timeout), then returns the batch to the caller. Key observations: 1. **No broker-side optimization** — `batchReceive` does not reduce the number of requests to the broker. Messages are still pushed one-by-one (or unpacked from broker-level batches individually) into the receiver queue. The "batch" is purely a client-side grouping. 2. **Equivalent to a `receive()` loop** — The same behavior can be achieved by calling `receive()` in a loop with your own accumulation logic and timeout control. The API is a convenience wrapper, not a performance optimization. 3. **Go client context** — In the Go client, users already have full control over how they consume messages via channels or callbacks. Adding a `batchReceive` API would just wrap `Receive()` / `Chan()` in a loop without providing additional value at the protocol level. If there's a specific use case where you believe batch receive would provide tangible benefits (e.g., reducing lock contention, simplifying consumption patterns), we'd be happy to discuss further. Otherwise, we'd recommend implementing the accumulation logic in application code, which gives more flexibility over batching strategy. -- 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]
