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
There is no control for the event loop selection outside the controller method e.g. in TypedArgumentBinder #10742
Comments
It is probably the answer you are looking for but I think the solution is not to do network calls in the TypeArgumentBinder. I think you should move that logic (network requests) to a filter or to a controller method. |
I appreciate your advice but this would mean rewriting hundreds of controller methods. and some of the code is out of our control. e..g fetching the token. we need to clean up the MN versions, we're still getting errors from JWKS verification even we are trying to offload to the blocking scheduler.
|
have you tried the executor service option described here: https://www.youtube.com/watch?v=W6iztOuulVU ? |
I would probably put your code in a filter which you can annotate to @ExecuteOn, populate a request attribute in the file and then keep the logic of the request argument simple fetching from request attribute. |
Our current workaround was rewriting all the involved HTTP client to reactive ones and then offload the fetching to custom schedulers with I've seen the solution with filter with authentication because I wondered how it is possible that it works. There are workarounds but all of these makes using the framework very painful. |
I understand but your application was blocking the Netty event loop and this exception pointed you to a necessary change. I don't think don't throwing an exception was a better alternative. |
but if I understand it properly, none of these would be an issue when the app will be fully using virtual threads, isn't it? so wouldn't be better to have some flag to switch to the virtual threads globally much better solution? I would still prefer having a error logged for at least one minor release before throwing the error - something like Gradle is doing. throwing an error might be nice when developing new app but for large legacy system is a nightmare. what if there is a blocking call somewhere hidden and we don't have a valid test case for it yet. logging an error is something that can't be easily ignored if you use tools like Sentry but it still won't affect the user. |
Moving everything to virtual threads by default isn't happening anytime soon. What you could instead try is add an empty request filter that has |
thank you @yawkat for sharing the trick. indeed having a filter that executes on
|
Expected Behavior
Either the code preceding the controller method execution such as authentication resolution or argument binding respect the event loop selection for the controller or every API such as
TypedArgumentBinder
supports reactive programming.Actual Behaviour
The
@ExcuteOn
annotation only applies to the body of the controller methods. Anything outside the controller method such as argument binding usingRequestArgumentSatisfier
andTypedArgumentBinder
always happens on the Netty event loop making fixing the new blocking operation exceptions very verbose and unfriendly.Steps To Reproduce
Checkout the repository below with branch example-with-blocking-http-call-in-arugment-binder and run
FactsControllerTest
.Environment Information
JDK 21
Example Application
https://github.com/musketyr/micronaut-blocking-calls-in-binders-issue/tree/example-with-blocking-http-call-in-arugment-binder
Version
4.4:0
The text was updated successfully, but these errors were encountered: