@RequestScope cannot be used with HTTP client blocking requests about micronaut-core HOT 7 CLOSED

@BharathMC seems to be an issue with @RequestScope controllers only, removing this annotation and making it singleton works fine. We will look into it and thanks for the report

from micronaut-core.

Got it. So, the issue is @requestScope is creating the bean for the HttpClient but it is not cleaning up the resources on completion of the request.

Which breaks the definition of @RequestScope : A CustomScope that creates a new bean for every HTTP request.

And this is the case with both blocking and non-blocking HttpClient usage.

We will wait for the bug fix.

Thanks

from micronaut-core.

No the issue is that a new client is created and the shutdown down for each request. The contract for request scope is correct what is incorrect is the shutting down of the clients which should be held in a different scope it seems

from micronaut-core.

Also FWIW why do you need RequestScope? In general it is an anti pattern

from micronaut-core.

As the doc says :
@requestScope scope is a custom scope that indicates a new instance of the bean is created and associated with each HTTP request.

The problem with removing @requestScope and making it singleton, shares the thread objects (thread local vars).
We are using this for keeping each incoming requests isolated and all the data stored per request is kept in thread local variables. Basically thread safety. Each incoming request will have complex interception and the data needs to be maintained only for that thread and once the request is closed, we don't keep that info anymore. This is the same design we follow for SpringBoot and Helidon based libraries and as well and it works well, but facing issue with microanut framework. Either ways it is a bug.

So, it would be great if this issue gets fixed.

Thanks

from micronaut-core.

we will fix it but in general it doesn't change that we regard ThreadLocal state is an anti-pattern. If you need a new object per request you can use @Prototype scope. Associating local object state with a thread increases memory for each thread and doesn't play well with virtual threads (scoped values hope to fix this but not JDK has these stable yet). Associating state with threads also doesn't work well with reactive or non-blocking use cases.

from micronaut-core.

Thank you for fixing this quickly, @graemerocher.

Sure, meanwhile will explore @Prototype for scope till the fix is available to public as part of release.

from micronaut-core.