-
Notifications
You must be signed in to change notification settings - Fork 107
feat: dynamic flow control part 1 - add FlowController to Batcher #1289
feat: dynamic flow control part 1 - add FlowController to Batcher #1289
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1289 +/- ##
============================================
+ Coverage 79.53% 79.65% +0.11%
- Complexity 1239 1248 +9
============================================
Files 209 209
Lines 5434 5461 +27
Branches 454 464 +10
============================================
+ Hits 4322 4350 +28
+ Misses 933 928 -5
- Partials 179 183 +4
Continue to review full report at Codecov.
|
@igorbernstein2 This part should be ready for review :) |
gax/src/test/java/com/google/api/gax/batching/BatcherImplTest.java
Outdated
Show resolved
Hide resolved
gax/src/test/java/com/google/api/gax/batching/BatcherImplTest.java
Outdated
Show resolved
Hide resolved
gax/src/test/java/com/google/api/gax/batching/BatcherImplTest.java
Outdated
Show resolved
Hide resolved
gax/src/test/java/com/google/api/gax/batching/BatcherImplTest.java
Outdated
Show resolved
Hide resolved
|| flowController.getMaxOutstandingRequestBytes() | ||
>= batchingSettings.getRequestByteThreshold(), | ||
"if throttling and batching on request bytes are enabled, FlowController#maxOutstandingRequestBytes must be greater or equal to requestByteThreshold"); | ||
} |
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.
Can these checks be moved to FlowControlSettings#build()?
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.
These are the checks to make sure flow control limits are >= batch sizes so it won't deadlock. I also added the checks in BatchingSettings. In case where BatcherImpl is constructed with a FlowController, we'll need to validate the settings here also. (and FlowControlSettings doesn't have any information about batch settings)
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.
ok, makes sense
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.
Please check my comment about construction BatcherImpl directly via FlowController
that looks really suspicious, and should be avoided. If we avoid it, we can also get rid of this check. The fact that we need this check here is a one more indicator that flowControlelr should not be passed directly to BatcherImpl.
LGTM, @vam-google can you take a look and let us know if you are ok with merging this? |
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.
Most of the comments are minor or questions. My only real concern is the flowController
vs new FlowController(batchingSettings.getFlowControlSettings())
thing. Please check the corresponding comment for more details.
|| flowController.getMaxOutstandingRequestBytes() | ||
>= batchingSettings.getRequestByteThreshold(), | ||
"if throttling and batching on request bytes are enabled, FlowController#maxOutstandingRequestBytes must be greater or equal to requestByteThreshold"); | ||
} |
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.
Please check my comment about construction BatcherImpl directly via FlowController
that looks really suspicious, and should be avoided. If we avoid it, we can also get rid of this check. The fact that we need this check here is a one more indicator that flowControlelr should not be passed directly to BatcherImpl.
@@ -174,6 +174,21 @@ public BatchingSettings build() { | |||
settings.getDelayThreshold() == null | |||
|| settings.getDelayThreshold().compareTo(Duration.ZERO) > 0, | |||
"delayThreshold must be either unset or positive"); | |||
if (settings.getFlowControlSettings().getLimitExceededBehavior() |
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.
Regardless of how the flowController vs flowControllerSettings
issue gets resolved, please make sure that this complex logic exists in only one place (now there are two: here and in BatcherImpl constructor) and reused if needed.
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.
Removed the checks in BatchingSettings and only kept them in BatchImpl. I guess it really depends on the Batcher how these settings are used, so it makes more sense to enforce the checks there?
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.
Sounds reasonable
|| settings.getRequestByteThreshold() == null | ||
|| settings.getFlowControlSettings().getMaxOutstandingRequestBytes() | ||
>= settings.getRequestByteThreshold(), | ||
"if throttling and batching on request bytes are enabled, FlowController#maxOutstandingRequestBytes must be greater or equal to requestByteThreshold"); |
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.
Should those error messages start with capital letter? Also, please split the error sting into mutiple lines, as this one is 160+ characters long and exceeds the formatting limits.
new BatcherImpl<>( | ||
SQUARER_BATCHING_DESC_V2, | ||
callLabeledIntSquarer, | ||
labeledIntList, | ||
batchingSettings, | ||
EXECUTOR)) { |
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.
Minor: Looks like this long block is repeated in each test (with an extra flowController
parameter sometimes). It uses the try-with-resources block, which leads into heavy multiline formatting. Pleas consider putting the creation of this in the private method, so the try blocks can look something like:
try (BatcherImpl batcher1 = createBatcher(null)) {
}
// ...
try (BatcherImpl batcher2 = createBatcher(flowController)) {
}
That will let save quite a few lines of code here and in general make these tests less scary-looking.
} | ||
}); | ||
try { | ||
future.get(100, TimeUnit.MILLISECONDS); |
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.
If TimeoutException
is expected, can we make this shorter (i.e. since we are guaranteed to wait, lets wait as little as possible, otherwise it may quickly lead to really long-running unit tests, which should not happen). This comments/question applies to all timed get()
s in this test.
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.
LGTM
Merge-on-green attempted to merge your PR for 6 hours, but it was not mergeable because either one of your required status checks failed, one of your required reviews was not approved, or there is a do not merge label. Learn more about your required status checks here: https://help.github.com/en/github/administering-a-repository/enabling-required-status-checks. You can remove and reapply the label to re-run the bot. |
🤖 I have created a release \*beep\* \*boop\* --- ## [1.62.0](https://www.github.com/googleapis/gax-java/compare/v1.61.0...v1.62.0) (2021-02-25) ### Features * deprecate RetrySettings.isJittered [gax-java] ([#1308](https://www.github.com/googleapis/gax-java/issues/1308)) ([68644a4](https://www.github.com/googleapis/gax-java/commit/68644a4e24f29223f8f533a3d353dff7457d9737)) * dynamic flow control part 1 - add FlowController to Batcher ([#1289](https://www.github.com/googleapis/gax-java/issues/1289)) ([bae5eb6](https://www.github.com/googleapis/gax-java/commit/bae5eb6070e690c26b95e7b908d15300aa54ef1c)) ### Bug Fixes * prevent unchecked warnings in gax-httpjson ([#1306](https://www.github.com/googleapis/gax-java/issues/1306)) ([ee370f6](https://www.github.com/googleapis/gax-java/commit/ee370f62c5d411738a9b25cf4cfc095aa06d9e07)) * remove unused @InternalExtensionOnly from CallContext classes ([#1304](https://www.github.com/googleapis/gax-java/issues/1304)) ([a8d3a2d](https://www.github.com/googleapis/gax-java/commit/a8d3a2dca96efdb1ce154a976c3e0844e3f501d6)) ### Dependencies * update google-auth-library to 0.24.0 ([#1315](https://www.github.com/googleapis/gax-java/issues/1315)) ([772331e](https://www.github.com/googleapis/gax-java/commit/772331eda5c47e9de376e505e7d8ee502b01ec72)) * update google-common-protos to 2.0.1 ([772331e](https://www.github.com/googleapis/gax-java/commit/772331eda5c47e9de376e505e7d8ee502b01ec72)) * update google-http-client to 1.39.0 ([772331e](https://www.github.com/googleapis/gax-java/commit/772331eda5c47e9de376e505e7d8ee502b01ec72)) * update google-iam ([#1313](https://www.github.com/googleapis/gax-java/issues/1313)) ([327b53c](https://www.github.com/googleapis/gax-java/commit/327b53ca7739d9be6e24305b23af2c7a35cb6f4d)) * update gRPC to 1.36.0 ([772331e](https://www.github.com/googleapis/gax-java/commit/772331eda5c47e9de376e505e7d8ee502b01ec72)) * update opencensus to 0.28.0 ([772331e](https://www.github.com/googleapis/gax-java/commit/772331eda5c47e9de376e505e7d8ee502b01ec72)) * update protobuf to 3.15.2 ([772331e](https://www.github.com/googleapis/gax-java/commit/772331eda5c47e9de376e505e7d8ee502b01ec72)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
Splitting #1288 into smaller prs.
Implementing go/veneer-dynamic-flow-control. Adding a FlowController to Batcher so in flight requests can be throttled.