Qute requestScoped bean resolution.

[TonyWeston]

If I have a requestScoped bean, that returns a CompletionStage, then this code will fail

{#if  cdi:area.customerList.size() eq 0}
   No Customers
{#else}

  {#for customer in cdi:area.customerList}
      {customer.name} </br>
  {/for}
{/if}

in the above, area.customerList, returns a completion stage, that provides a list of customers (since this operation to initially fetch the list of customers is expensive. Further calls to area.customerList, returns the same, now completed, completionStage).
It fails, because the first #if is decided only when the area.customerList has completed, and so QUTE runs the code after the #if, in a new thread , to prevent blocking. This is good.

However, this means when {#for customer in cdi:area.customerList}, is evaluated, this is running in a different thread, to the request thread, and the cdi:area requestScoped bean is no longer found.

I can fix this pretty easy, by adding this to the top, and then referring to areabean when I want my list of customers.
{#let areabean=cdi:area}

But, this is just a work around - if there were #included templates further down, which also made use of the area bean, i would be forced to pass this areabean in, rather than allow that included template to resolve the bean itself.

Personally, I think that this could be better - Qute should only ever resolve CDI beans, in the request thread (The thread that called TemplateInstance.render()) , maybe by resolving all beans in the template, and its included subtemplates upfront, OR, by making sure that the requestScope is inherited by any threads that are spawned during the processing of the template, to avoid blocking.

Opinions?

[quarkus-bot[bot]]

/cc @mkouba (qute)

[mkouba]

area.customerList will, first time, get a list of customers. Subsequent times, it will just return the same list.

So it returns a cached CompletionStage, right?

Being able to inject beans anywhere, is a great advantage - it allows complex screens, with many sub components, to have any data they require to be encapsulated into the bean for that component, and not clutter the controller.

I get your point. My point is that Qute itself does not care about threads and has currently no way to identify the original thread. Also in an async environment it's not enough to use the original thread - the CDI request context must be propagated and it might happen that it's not active (context propagation in reactive is a complex topic and the implementation is tricky).

I'd recommend you to (A) use the {#let} workaround or (B) use a different scope for your bean (note that @Dependent beans are shared across all expressions in a template for a single rendering operation, and destroyed after the rendering finished).

[TonyWeston]

So it returns a cached CompletionStage, right?

Yes... something like

@RequestScoped
public class Area {
	private CompletionStage<List<Customers>> customerList;
	
	@Inject
	AreaService areaService;
	
	public CompletionStage<List<Customers>> getCustomers(){
		if (customerList==null) {
			customerList = areaService.resolveCustomers(getSessionArea());
		}
		return customerList;
	}
}

...and has currently no way to identify the original thread.

There will be some user code that calls TemplateInstance.render(), which will be from the 'original thread'. When the template is compiled, a list of these cdi:bean injects could be made, so when TemplateInstance.render() is called, those beans can be realised upfront from the thread, that render() is called?

[TonyWeston]

I will try @dependent scope. Sounds as if it will solve the problem :-)

[mkouba]

There will be some user code that calls TemplateInstance.render(), which will be from the 'original thread'. When the template is compiled, a list of these cdi:bean injects could be made, so when TemplateInstance.render() is called, those beans can be realised upfront from the thread, that render() is called?

As I mentioned above - the thread might not be enough, the request context may be deactivated.

Hmm, I've tried to write a test that would simulate your problem but with no success. I mean even if cdi:area.customerList is executed on a different thread then the content of the section should be executed on the original thread.

Could you pls try to create a simple reproducer app that demonstrates the problem?

[mkouba]

FYI this is the test: https://github.com/mkouba/quarkus/blob/qute-async-thread-test/independent-projects/qute/core/src/test/java/io/quarkus/qute/AsyncThreadTest.java

[TonyWeston]

There you go.. If you visit /test , you get the error.

TestRequestScopeQute.zip

Incidentally. in TestResource, I am doing the below. So, the render() method must block until the page is fully rendered, and so the Requestcontext must still exist at this point.

    @GET
@Produces(MediaType.TEXT_HTML)
public Response get() {
	TemplateInstance testpagein = testpage.instance();
	String responseHTML = testpagein.render();
	

	return Response.ok(responseHTML).build();
}

[mkouba]

Hm, it depends on the type of the chained operation, i.e. there's a difference between thenApply() and thenCompose().

In any case, there's no guarantee what thread is actually used.

[mkouba]

To be honest I have no idea how to fix this kind of problem.

The only thing that should work is to (A) @Inject Vertx and then vertx.executeBlocking() to execute the async action or (B) use the MP Context Propagation; i.e. @Inject ManagedExecutor and then managedExecutor.submit(). In both cases the request context should be propagated automatically.

[manovotn]

(B) use the MP Context Propagation; i.e. @Inject ManagedExecutor and then managedExecutor.submit(). In both cases the request context should be propagated automatically.

Note that you can also use ThreadContext from MP CP if that suits you better than whole executor.

[TonyWeston]

THANK YOU

(B) use the MP Context Propagation; i.e. @Inject ManagedExecutor and then managedExecutor.submit(). In both cases the request context should be propagated automatically.

This was the key.

The code I provided only demonstrated an error I was getting. The real code, used okHttpClient to retrieve data from another server. The root cause of things breaking, was okHttpClient creating its own threads, to handle the async communication. These threads found their way into into Qute, and when hitting a cdi:bean, resulted in the very same error seen in the example code. Following your advice, I've made some code to make okHttpClient use the ManagedExecutor.

And everything now works perfectly.

Thanks again.

[manovotn]

Glad to hear that! :)