Guarantee no requests are running at shutdown event

[LarsSven]

Hello,

I was reading through the Quarkus shutdown guide at https://quarkus.io/guides/lifecycle#graceful-shutdown, and I couldnt'find the full answer to my question. Basically, I have some logic I want to execute for my gRPC server at graceful shutdown, but I want to make sure requests are not running by the time I run the shutdown hook. I don't care about whether my requests return a useful result or just disconnect, but I do care that I run some cleanup code that shuts down a set of containers without a request that was already running spinning up a new container post-cleanup. Is this possible in Quarkus?

[LarsSven]

Also as a separate question, it says that quarkus.shutdown.timeout is only supported on HTTP (https://quarkus.io/guides/lifecycle#graceful-shutdown), is this correct, or can I also give the application some time to finish all requests when it is a gRPC server?

[alesj]

@geoand what would we need for this?
@cescoffier ^ ?

Perhaps if you use Vert.x based gRPC, this could already work?

[geoand]

@alesj to do essentially the same thing that the Quarkus Vert.x HTTP integration does for the Quarkus gRPC integration

[alesj]

OK, I see.
Might be (easily) doable with Vert.x gRPC -- as it's Vert.x after all,
but dunno - atm - how this can be applied to old gRPC ...

[alesj]

@LarsSven can you try if this already works -- as it might ...

You need this

• use new Vert.x gRPC server
• set quarkus.shutdown.timeout > 0
• not be in dev mode

[LarsSven]

@alesj I will look into it and let you know.

Are there any upsides/downsides to the new gRPC server vs the old one? I can't find the tradeoffs in the documentation but I assume there is reason the old one is enabled by default.

[alesj]

there is reason the old one is enabled by default

Just to be back compatible.
We will switch the default at one point, hopefully asap.

I can't find the tradeoffs in the documentation

One less server / port, one less configuration (as you can mostly just live off existing HTTP config).
And the implementation is in-house.
Just from the top of my head ...

[LarsSven]

@alesj I can confirm that switching over to using Vert.x under the hood indeed makes the shutdown work. That's honestly great!

[geoand]

@alesj @cescoffier I wonder if the with the move Vert.x 5 at some point, it will also make sense then to change the default gRPC implementation of Quarkus to the Vert.x one.

[LarsSven]

@gsmet @geoand @cescoffier would you maybe know something about how to ensure no requests are running when the shutdown code is running?

[geoand]

I am pretty sure there is currently no way to do that. The shutdown tasks execute when the application has been signaled to shutdown.

[cescoffier]

For HTTP (and gRPC when using a single server), there is a graceful shutdown filter that waits for a request to be processed before terminating, rejecting all new requests.

Quarkus Messaging has something relatively similar in place (for events).