grssam commented on PR #23398:
URL: https://github.com/apache/pulsar/pull/23398#issuecomment-2456268584
> Sure, I was suggesting to send a failure `ServerError.Throttled` to
producer as it is just a notification from server to client. and let client
receive this error during publish and do necessary backoff.
Ah got it now. So there are a few reasons for this not being a "response" to
a send request :
* `CommandSendError` command doesn't have the provision to notify the time
for which the producer is throttled. Adding that optional field just for one of
the `ServerError` enums doesn't seem right.
* Due to the distributed nature of a producer, relying on communication as a
response to a `Send` request might not work out. Suppose 10 producers connected
to a topic, one of them might not even have produced yet but the quota might
have breached.. So we need to send communication to all 10 producers to
throttle themselves.
* Throttling doesn't actually lead to failures - If the client has
reasonable timeouts (default being 30s is more than reasonable) then even with
throttling, the message produce will pass. Moreover, every producer could be
joining in with a different client sentTimeout value.. Thus, it is not possible
in the current protocol approach to manage or figure out whethar a throttling
on the broker side would actually lead to client side error at all. Thus, this
is decoupled from send response.
> Umm.. That should not be true because we can increase this version when we
want to check client's compatibility and this should be the example of this
usecase.
I suspect this is done because not every client wanted to implement a
feature present in protocol version X, but still wanted to implement something
present in version Y where X < Y.. thus this independent approach of "supported
feature flag" was introduced.
[This](https://apache-pulsar.slack.com/archives/C5ZSVEN4E/p1726845929631179) is
the slack discussion thread if you want to join in the conversation.
--
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]
