You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@helix.apache.org by "junkaixue (via GitHub)" <gi...@apache.org> on 2023/05/04 22:54:13 UTC

[GitHub] [helix] junkaixue commented on pull request #2463: Initial commit for capacity based throttler for state transition control

junkaixue commented on PR #2463:
URL: https://github.com/apache/helix/pull/2463#issuecomment-1535504290

   I have a general thought on this. This is more like N -> N+1 triggered problem in BestPossibleStage and we solve it at IntermediateStage for throttling.
   
   I am more preferring to have consistent behavior. For example, we found delay problem in WAGED, then we solve it in WAGED. If the N -> N+1 is problem in WAGED, we should solve it in WAGED. WAGED is the place to own the constraint-based info, filtering and so on. Apply it to other stages could not be that valuable.
   
   With this implementation, the behavior of throttling will be hard to explain because it is mixing of: constraints and message throttling. I can foresee the even worse debuggability of introducing this when users asks why this throttled, why this not.
   
   


-- 
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: reviews-unsubscribe@helix.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@helix.apache.org
For additional commands, e-mail: reviews-help@helix.apache.org