Yes, I agree with `it’s always possible that client got timeout`. But mostly, it’s an UNKNOWN state, producer didn’t know whether the message was persisted or not. Fail-fast strategy could let producers know this message was rejected by broker clearly.
Thanks, Tao Jiuming > 2022年4月7日 下午3:53，Haiting Jiang <jianghait...@apache.org> 写道： > >> 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
