-
Notifications
You must be signed in to change notification settings - Fork 3.4k
HBASE-29229 Throttles should support specific restrictions for atomic workloads #6866
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Out of morbid curiosity, I'm going to request a review from copilot |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR extends throttling support by introducing two new atomic quota types—atomic read size and atomic request number—to better isolate and restrict atomic workloads. Key changes include adding an extra boolean parameter to quota‐checking methods, updating rate limiter implementations to accommodate atomic quotas, and propagating these changes through tests, protocol buffers, and exception handling.
Reviewed Changes
Copilot reviewed 25 out of 25 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| hbase-server/src/test/java/org/apache/hadoop/hbase/quotas/TestDefaultOperationQuota.java | Updated test calls to include the new isAtomic parameter. |
| hbase-server/src/test/java/org/apache/hadoop/hbase/quotas/TestDefaultAtomicQuota.java | Introduced new tests for atomic throttling behavior. |
| hbase-server/src/test/java/org/apache/hadoop/hbase/quotas/TestAtomicReadQuota.java | Modified tests to use the updated quota setup methods and added atomic quota verifications. |
| hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java | Updated checkBatchQuota to forward the isAtomic flag. |
| hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/TimeBasedLimiter.java | Added new RateLimiter instances for atomic quotas and updated the checkQuota method accordingly. |
| hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/RpcQuotaManager.java | Modified method signature to pass the isAtomic flag. |
| hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/RegionServerRpcQuotaManager.java | Updated quota checks to propagate the atomic flag based on action type. |
| hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/QuotaUtil.java | Introduced new constants for default atomic quotas. |
| hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/QuotaLimiter.java and related quota classes | Updated method signatures to accommodate the extra atomic parameter. |
| hbase-protocol-shaded/src/main/protobuf/server/Quota.proto | Added new enum definitions for atomic throttling. |
| hbase-client/src/main/java/org/apache/hadoop/hbase/shaded/protobuf/ProtobufUtil.java, ThrottleType.java, ThrottleSettings.java, RpcThrottlingException.java | Updated client-side handling of atomic quota types and associated error messages. |
|
Wow, perfection on the first try 😄 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Test failure is unrelated |
a95c453 to
ad22d1d
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
ndimiduk
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Scrolling through on mobile, so it's difficult to investigate details at the moment.
Should we also support a throttle based on atomic write volume? I think that atomic operations are not read/write symmetrical -- that is, we can have a CAS that reads a very small value but writes a very large value. It's unclear to me how we determine the read size and if we can distinguish that from write size.
If these are two distinct metrics, I think that we should support two distinct throttles. If they are recorded as a single metric, we should use a name that does not specify read or write, something like "atomic_bytes_processed".
|
Quotas have some precedent for calculating a best guess at a mutations write size via this helper, and it uses that to support write volume specific throttles. IMO we could add another limiter here based on atomic write volume |
It ran but did it have you any actionable feedback? Looks like it just wrote a change summary. |
|
Yeah it has no feedback:
Then I did a self-review and found a few things I wanted to cleanup, that imo it could have caught 😢 |
ad22d1d to
eb31063
Compare
|
I just pushed an update which includes an atomic write size throttle |
| void forceSynchronousCacheRefresh() { | ||
| refreshChore.chore(); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This addition is a bit weird, but I noticed that many tests were flappy when running locally due to the chore missing its trigger. So this is a more forceful approach that improves the test reliability
ndimiduk
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for covering the write case.
|
🎊 +1 overall
This message was automatically generated. |
|
💔 -1 overall
This message was automatically generated. |
… workloads (#6866) Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
… workloads (#6866) Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
… workloads (#6866) Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
… workloads (#6866) Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
… workloads (#6866) Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
… workloads (#6866) Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
… workloads (#6866) Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
… workloads (#6866) Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
… workloads (apache#6866) (apache#6882) (apache#6883) (will be in 2.6.3) Signed-off-by: Nick Dimiduk <ndimiduk@apache.org> Co-authored-by: Ray Mattingly <rmattingly@hubspot.com>
… workloads (apache#6866) (apache#6882) (apache#6883) (will be in 2.6.3) Signed-off-by: Nick Dimiduk <ndimiduk@apache.org> Co-authored-by: Ray Mattingly <rmattingly@hubspot.com>
…rictions for atomic workloads (apache#6866) (apache#6882) (apache#6883) (will be in 2.6.3) Signed-off-by: Nick Dimiduk <ndimiduk@apache.org> Co-authored-by: Ray Mattingly <rmattingly@hubspot.com>
…rictions for atomic workloads (apache#6866) (apache#6882) (apache#6883) (will be in 2.6.3) Signed-off-by: Nick Dimiduk <ndimiduk@apache.org> Co-authored-by: Ray Mattingly <rmattingly@hubspot.com>
…rictions for atomic workloads (apache#6866) (apache#6882) (apache#6883) (will be in 2.6.3) Signed-off-by: Nick Dimiduk <ndimiduk@apache.org> Co-authored-by: Ray Mattingly <rmattingly@hubspot.com>
… workloads (apache#6866) (apache#6882) Signed-off-by: Nick Dimiduk <ndimiduk@apache.org> Co-authored-by: Ray Mattingly <rmattingly@hubspot.com>
Pretty straightforward, and well tested here imo: atomic requests can be uniquely expensive, and it would be nice to throttle them in isolation.
cc @ndimiduk @hgromer