We also encountered the same problem. When the current limit is triggered, fast failure is an ideal way to deal with it. In this way, the behavior of the current limit itself can be notified to the client-side in time, and the user can feel the behavior of the current limit, instead of letting the user Send or receive a timeout.
But for pulsar's own model, this thing doesn't seem to be handled very well, because the current limit is based on the connection itself, as Haiting and Lari said, if multiple topics reuse the same connection, then this situation will get tricky. So can we introduce other commands in Proto here, because the broker knows that the client has triggered various current-limiting thresholds? If the current-limiting threshold is triggered, the broker will notify the client-side of the information. -- Thanks Xiaolong Ran Lari Hotari <l...@hotari.net> 于2022年4月8日周五 00:21写道： > > IMO, the more serious problem about `disableAutoread` is > > Producer/Consumer isolation issue, > > since they shares the connection. For example, if topic-A is > rate-limited, > > topic-B in the same client is also affected. > > Exactly. The rate-limiting won't even work properly since other rate > limiters operating on the same connection will enable autoread and this > results in inconsistent behavior. > > -Lari > > On Thu, Apr 7, 2022 at 10:53 AM Haiting Jiang <jianghait...@apache.org> > wrote: > > > > send receipt to producer, the producer maybe timeout already. > > > > It's always possible that client got timeout, but the message is actually > > successfully written, > > causing by network issue. > > > > IMO, the more serious problem about `disableAutoread` is > Producer/Consumer > > isolation issue, > > since they shares the connection. For example, if topic-A is > rate-limited, > > topic-B in the same > > client is also affected. > > > > Thanks, > > Haiting > > > > On 2022/04/07 07:13:50 Jiuming Tao wrote: > > > Hi all: > > > According to the issue ( > > https://github.com/apache/pulsar/issues/15038), when producer send a > > message to broker and broker rate-limited at that time, the request will > > blocked in buffer, after broker read the message and send receipt to > > producer, the producer maybe timeout already. > > > So, in the case, do we need to provider a new flow-control > > strategy(fail-fast)? It can be configurable, when broker in rate-limit, > > broker not `disableAutoread` and reply a `FlowControlException` instead. > > > > > > Thanks, > > > Tao Jiuming > > >
