+1 (binding) I apologize for the late reviews on the PIP-385 document PR, https://github.com/apache/pulsar/pull/23398.
As this is already a vote thread, I support accepting PIP-385, although the current design contains a few major challenges that haven't been addressed yet. From my point of view, we can close the vote and accept this PIP. To make the implementation meet its goals, these design challenges will need to be addressed as part of future changes and captured in the PIP document to ensure the design is properly documented. We cannot simply proceed in a waterfall manner and expect that the design for PIP-385 is complete with implementation as the next phase. There will need to be iteration between design, experimentation, implementation, and validation. The key design challenges that need to be addressed include: - Flow Control solution to avoid TCP-level throttling: The proposed throttling command and period-based solution faces challenges due to queuing between client and broker. When a client stops sending, the broker continues receiving messages in the queue, making flow control less accurate. While a permit/credit-based approach was initially considered, the throttling command solution can work with additional design considerations and will most likely lead to a simpler solution than a permit/credit based approach for producer flow control. - Queue Size Estimation: For the flow control solution, the broker needs a way to estimate messages queued between client and broker. One potential solution is using enhanced Ping/Pong commands with request IDs and timestamps to calculate RTT and estimate the queue size. This could help the broker send throttle commands early enough to avoid TCP-level throttling, which cannot be removed even when the client supports PIP-385. Removing TCP-level throttling would result in out-of-memory issues or higher memory usage compared to the current behavior in the Pulsar Broker. - Fair Queuing for Multi-Producer Topics: The current design doesn't address how to ensure fair quota sharing among multiple producers on a topic. While PIP-322 has a simple fairness solution, solving fair queuing for this new throttling mechanism will likely be more challenging. Additionally, there's a Pulsar Java client issue (out of scope for PIP-385): - Non-blocking Producer Flow Control: The current blocking approach in the Java client is problematic for async APIs. A separate PIP may be needed to implement non-blocking producer flow control for the Pulsar Java client async API. We aren't addressing a simple problem. That's why producer flow control hasn't been solved in Pulsar by now. Accepting PIP-385 will be beneficial as it commits us as a community to solving this problem and continuing to make progress. Thank you, Girish, for driving this effort! -Lari On Mon, 11 Nov 2024 at 09:02, Girish Sharma <scrapmachi...@gmail.com> wrote: > > Hi Pulsar dev community, > > I would like to start the voting thread for PIP-385 Add rate limit > semantics to pulsar protocol and Java Client. > > Proposal PR: https://github.com/apache/pulsar/pull/23398 > Rendered PIP - > https://github.com/apache/pulsar/blob/9e4542d83faa2cf5afdca7b45e172a5b74ea6e2a/pip/pip-385.md > > Discussion Thread: > https://lists.apache.org/thread/9wddmj4o5mrdst427r40rr7phqb05y6s > > Please review the PIP document and vote! > > Regards > -- > Girish Sharma
