Skip to content
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.

Sign up for GitHub

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

Handle response correctly when request already cancelled #110249

Merged
merged 1 commit into from
Jun 28, 2024
Merged

Handle response correctly when request already cancelled #110249

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion .../internalClusterTest/java/org/elasticsearch/http/netty4/Netty4ChunkedContinuationsIT.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -646,7 +646,11 @@ public void accept(RestChannel channel) {
client.execute(TYPE, new Request(), new RestActionListener<>(channel) {
@Override
protected void processResponse(Response response) {
localRefs.mustIncRef();
// incRef can fail if the request was already cancelled
if (localRefs.tryIncRef() == false) {
assert localRefs.hasReferences() == false : "tryIncRef failed but RefCounted not completed";
return;
}
Copy link
Contributor Author

@nicktindall nicktindall Jun 27, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels like it could hide the test being broken (i.e. if we always cancel before the call to processResponse it'll happily pass without testing anything).

Another approach would be to put a synchronization point after the call to sendResponse, which we wait on before cancelling the request. That way we could be sure we'd begun sending the response before the cancellation? but perhaps handling cancellation prior to the response being sent is part of the test?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we could just call tryIncRef, and if it fails to increment the counter, it should also not decrement it later (by virtue of channel.sendResponse not sending the chunked response)?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the current change is fine. We also do something similar at prepareRequest a few lines above.

elasticsearch/modules/transport-netty4/src/internalClusterTest/java/org/elasticsearch/http/netty4/Netty4ChunkedContinuationsIT.java

Line 637 in ef52f8c

if (localRefs != null && localRefs.tryIncRef()) {

perhaps handling cancellation prior to the response being sent is part of the test?

I think so. The random sleep in the test method is intended to have cancellation happen in different places, including in prepareRequest where no response is ever generated.

it should also not decrement it later (by virtue of channel.sendResponse not sending the chunked response)?

I think this might not be the case. It seems that response is released if channel.sendResponse fails to send.

elasticsearch/server/src/main/java/org/elasticsearch/http/DefaultRestChannel.java

Lines 191 to 192 in ef52f8c

if (success == false) {
Releasables.close(toClose);

channel.sendResponse(RestResponse.chunked(RestStatus.OK, response.getResponseBodyPart(), () -> {
// cancellation notification only happens while processing a continuation, not while computing
// the next one; prompt cancellation requires use of something like RestCancellableNodeClient
Expand Down