Produce a 503 response when there no more worker threads to handle blocking requests

[cescoffier]

Fix #36860

[cescoffier]

I tested it manually. I didn't want to implement a test as it was going to be flaky. You need to overload the server, and on GH actions this is
1 - not necessarily easy to control
2 - can have unexpected consequences

The code is self-explanatory.

[ahus1]

@cescoffier - I see a System.out.println in the code, and I assume this might be a left-over code snippet from a debugging session that should be removed from the PR before merging it.

https://github.com/quarkusio/quarkus/pull/36869/files#diff-085d25b0aecabee93538a3b07042b3d26610fd0ffc7e0fa50ee35031ca995361R53

Besides that, I've reviewed it in the context of Keycloak, and the solution should work fine handling the exception thrown using RESTEasy reactive.

[cescoffier]

The exception is not handled in RestEasy reactive, but at the vertx http level directly. Thus it will work with RestEasy classic, reactive routes, gRPC...

[cescoffier]

System.out removed.

[ahus1]

@cescoffier - let me rephrase my previous statement: "The solution you are presenting here looks good and will work fine with Keycloak's use of RestEasy reactive". The only reason I used "should" was that I was just debugging the code, and not testing a full backport of change with Keycloak. Sorry for the confusion.

So TL;DR: This solution is fine for Keycloak

[quarkus-bot]

✔️ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.