Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Adding integration tests for search backpressure #5308
Adding integration tests for search backpressure #5308
Changes from 1 commit
7c34657
ec08b58
b1d0d32
09496ef
b272a12
cbeb1e6
16eba20
e336a04
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Putting these assertions in the async callback makes the output on a failure confusing, and also relies on the testing framework to fail on an uncaught exception. This also never counts down the latch in case of failure so
await
will have to wait until the timeout. It's better to make this callback just capture the exception, e.g.and then make assertions about
e
after you've blocked on the latch.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.
Added
ExceptionCatchingListener
as suggested to handle the exceptions and then asserting on the caught exceptions.In case of testcase failure, we are failing the testcase by calling
fail()
and it will finish the test execution, soCountDownLatch
doesn't have to wait until the timeout. In case when testcase passes, we are already decrementing the latch count after assertions.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.
@andrross Good point regarding test execution time!
@PritLadani May be set
ElapsedTimeTracker.SETTING_ELAPSED_TIME_MILLIS_THRESHOLD
CpuUsageTracker.SETTING_CPU_TIME_MILLIS_THRESHOLD
in the tests to 1 second instead of 15 seconds?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.
@ketanv3 Sure Ketan, will update the same in the next commit.
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.
fail()
doesn't do anything other than throw a AssertionError, so the test doesn't actually fail until the test method completes (after the latch times out) and something in the tear down method of the base class notices the unhandled exception and fails the test case.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.
With the newly introduced
ExceptionCatchingListener
, we will not encounter such case where latch has to wait until timeout happens.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.
The same comment applies here as well. We don't really have to simulate an
x%
CPU load fory
seconds.We just need to execute simple instructions that consume some CPU cycles, and be small enough that it can be interleaved with the cancellation checks. The busy-wait loop already takes care of re-running this 'work' until enough CPU cycles have been consumed for this task cancellation to take place.
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.
Noted.