Skip to content

Forward subscription cancellation from client to server #47555

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

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

alerosmile
Copy link

@alerosmile alerosmile commented Apr 25, 2025

This PR forwards the cancellation events from response Uni and Multi to the server by cancelling the gRPC stream.

@quarkus-bot quarkus-bot bot added the area/grpc gRPC label Apr 25, 2025
Copy link

quarkus-bot bot commented Apr 25, 2025

Thanks for your pull request!

Your pull request does not follow our editorial rules. Could you have a look?

  • title should not end up with dot
  • description should not be empty, describe your intent or provide links to the issues this PR is fixing (using Fixes #NNNNN) or changelogs

This message is automatically generated by a bot.

@alerosmile alerosmile changed the title Forward subscription cancellation from client to server. Forward subscription cancellation from client to server Apr 25, 2025
@geoand geoand requested review from alesj and cescoffier April 28, 2025 08:31

This comment has been minimized.

@alesj
Copy link
Contributor

alesj commented Apr 28, 2025 via email

Sorry for this, I was learning about the backpressure interface in gRPC.
@alerosmile
Copy link
Author

@alesj Sorry, forgot to remove some test code. I tried to find a solution for the back pressure handling.

Copy link
Member

@cescoffier cescoffier left a comment

Choose a reason for hiding this comment

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

LGTM, let's wait for @alesj and @jponge opinions.

This comment has been minimized.

@alerosmile alerosmile marked this pull request as draft April 30, 2025 07:37
@alerosmile
Copy link
Author

I've set this to draft because I'll provide some integration tests for this.

@alerosmile
Copy link
Author

@cescoffier please see #41776 (comment). What are the classes ManyToManyObserver and ManyToOneObserver used for?

// If this is set, the Multi was terminated by completion or failure, not by cancellation.
private final AtomicBoolean terminated = new AtomicBoolean();

private AtomicReference<ClientCallStreamObserver<I>> requestStreamObserver = new AtomicReference<>();
Copy link
Member

Choose a reason for hiding this comment

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

You might be able to condense the 2 atomic variables into one (requestStreamObserver, when null it means terminated)

Copy link
Author

Choose a reason for hiding this comment

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

Is it guaranteed that beforeStart is called in every case? If not, the emitter will never be terminated on error (after the change, emitter.fail() is only called if requestStreamObserver is not null).

@alerosmile
Copy link
Author

@cescoffier I've got an issue with this. If Vert.x is used on the server side (use-separate-server=false), the HTTP2 stream reset event is not forwarded to the service on Uni requests.

See io.vertx.core.http.impl.Http2ServerRequest.handleReset(long):
For those types of request, ended is set to true and no notification will be sent. I don't know if this can be changed somehow.

If this cannot be changed, this PR makes no sense because it doesn't work if Vert.x is used on the server side.

O2N and Vertx tests are disable because they fail (see quarkusio#47555 (comment) for details)
@alerosmile
Copy link
Author

Added some integration test. The tests in which Vert.x is used on the server side are disabled because they fail (see #47555 (comment)).

@geoand
Copy link
Contributor

geoand commented May 14, 2025

Is this ready to be reviewed?

@alerosmile
Copy link
Author

@geoand no, unfortunately not yet. I haven't found the time to comment on eclipse-vertx/vert.x#5562. This has to be solved otherwise this PR doesn't make any sense (see my previous comments here). Is anybody from the Quarkus core team here to help on the Vert.x issue?

@geoand
Copy link
Contributor

geoand commented May 15, 2025

Maybe @jponge or @alesj can help

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
5 participants