lhotari commented on PR #25061:
URL: https://github.com/apache/pulsar/pull/25061#issuecomment-3646690491

   > I understand that pre-estimating tokens and adjusting afterwards is an 
ideal model to reduce extra work. However, the issue addressed here is a 
concurrency problem: multiple dispatchers sharing a global limiter can observe 
the same available tokens and cause deterministic overshoot. 
   
   The concurrency problem would be addressed if the tokens are acquired before 
retrieving the entries and adjusted later. 
   
   In the current implementation, it would also be possible to change the 
current token acquisition so that tokens are consumed immediately after 
starting to dispatch the entries to a consumer and not after the operation 
completes.
   
https://github.com/apache/pulsar/blob/v4.1.2/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentDispatcherSingleActiveConsumer.java#L228-L231
   It's currently possible that entries get queued up in the broker side buffer 
for a consumer. The issue is #24926.
   
   > This PR consumes tokens before sending entries, preventing multiple 
dispatchers from using the same quota concurrently. While this may introduce 
minor delays, enforcing the configured rate is necessary, and this approach 
ensures correctness under concurrency. Pre-estimating tokens could be explored 
as a future optimization.
   
   I disagree on this approach since it would add more overhead to the system. 
It would be a breaking change to modify the default dispatch rate limiting in 
the way that you are suggesting since it adds overheads. A system with a 
certain capacity would have less capacity with this change.
   
   > I am using the ResourceGroup limiter, which is a global limiter. When 
multiple topics share this limiter, deterministic overshoot is observable. The 
traffic may return to normal in the next second, but I don't want to cause too 
much fluctuation.
   
   I'd assume that ResourceGroup limiter 
([PIP-82](https://github.com/apache/pulsar/blob/master/pip/pip-82.md)) isn't 
able to react to sudden changes in any case when limiters are across multiple 
brokers.
   
   
   
   
   
   
   


-- 
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]

Reply via email to