grssam commented on PR #23398: URL: https://github.com/apache/pulsar/pull/23398#issuecomment-2449401411
@rdhabalia Please find replies inline below > 1. what happens when broker sends `Throttle` Command to client? > > > * how does it impact client application? what happens when client-app calls `producer.sendAsync()` -> if client lib stops sending messages then client will eventually gets queue-full-execption? Yes, the client holds those messages in a new queue until the throttle time has passed. During this time, it is possible that queue full exception may also come if the user has configured that flag. This is explained in detail in this section of the PIP - https://github.com/apache/pulsar/pull/23398/files#diff-22a644af9af6cae8684b378ec31740275d87a6d96e7f823a63ded1ba86b2581cR265 Please let me know if the details need to be improved further. > * Or client will eventually get time-out exceptions for all the messages sitting into the queue>? I guess that could be the likely behavior and in that case, does it make sense to send publish-error-code instead `throttle-command` from broker. So, broker can send `ERROR_CODE.THROTTLING` and client can just handle it with same behavior as it has received `throttle-command` so, we might not need a separate command here and it can be achievable with an error-code. This behavior is unchanged overall. while the client is potentially preventing some of the messages sitting in the pending queue to be even sent out to the TCP pipe, the general behavior remains same with respect to timeout that anything in pending queue gets timedout if SendReceipt isn't received from server. The only difference is that now we don't throw a timeout exception if we know the client was being throttled for majority of the `messageSendTimeout` duration explained more in this section https://github.com/apache/pulsar/pull/23398/files#diff-22a644af9af6cae8684b378ec31740275d87a6d96e7f823a63ded1ba86b2581cR280 > 2. I think client doesn't have to send ACK for Throttle command back to broker as it's not useful to broker and it seems it's one side notification only. The only reason this throttle ack receipt is introduced is to handle older clients, or clients which haven't implemented this logic of stopping further production for the duration of the throttle time. This is important because if there is no throttle ack receipt , the server assumes that its a client that doesn't understand this new protocol and thus, the server will switch back to the older method of throttling - i.e. pausing TCP channel read. Let me know if that makes sense. > 3. How does client perform backoff? PIP says 1 second but server could have rate-limiting with different unit as well? and it doesn't make sense to configure on the client side? Are you referring to the throttling time calculation section - https://github.com/apache/pulsar/pull/23398/files#diff-22a644af9af6cae8684b378ec31740275d87a6d96e7f823a63ded1ba86b2581cR234 This is done on the server side.. so if the frequency/unit of token bucket refill is different than 1 second, it will be accommodated accordingly. The client doesn't make any assumptions on this frequency/unit, it simply blocks further produce until the time specified in the command. > are we also considering exponential backoff at client (starting with 10ms) and let client retry and see if producer can publish more messages or broker will again send throttle cmd/error. I thought about this, but fundamentally, since we are using uniformly filling token bucket design for rate limiting, it would be very difficult to figure out what kind of exponential back-off to use for sending back the throttling time back to the client. Moreover, since on server side, its a uniform token bucket, sending exponential back-off based time back to client may result in the client over-throttling than needed. -- 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]
