ArCContextProvider does not propagate request context

[FroMage]

As explained on Zulip and eclipse/microprofile-context-propagation#167, the current ArcContextProvider does not allow propagation of the request context, because it captures/restores values instead of the entire context.

We need to fix this because ATM it can't be used by reactive applications, which is the whole point of MP-CP.

Reproducer:

    @Inject
    MyRequestScopedBean bean;
    @Inject
    ThreadContext ctx;
    
    @GET
    @Path("datatypes")
    public CompletionStage<String> testRxDataTypes() {
        return ctx.withContextCapture(CompletableFuture.completedFuture(null))
                .thenApply(v -> bean.instanceCount())
                .thenApply(v -> {
                    Assertions.assertEquals(1, bean.instanceCount()); // should have only one bean per request
                    
                    return "OK";
                });
    }

    @GET
    @Path("datatypes-destroyed")
    public String testRxDataTypesDestroyed() {
        Assertions.assertEquals(1, bean.destroyed); // should have destroyed the previous request bean
        return "OK";
    }

@RequestScoped
public class MyRequestScopedBean {
    
    static int count;
    static int destroyed;
    
    @PostConstruct
    public void init() {
        // open a DB connection for this request
        count++;
    }
    
    @PreDestroy
    public void destroy() {
      // close a DB connection for this request
      destroyed++;    
    }
    
    public int instanceCount() {
        // how many DB connections have we opened so far?
        return count;
    }
}

Then make two REST calls to /datatypes then /datatypes-destroyed and observe that we create more than one request bean per request, and destroy a total of zero of them.

[manovotn]

    @PreDestroy
    public void destroy() {
      // close a DB connection for this request
      destroyed++;    
    }

This won't really work because CDI doesn't know when the request is truly over. The propagation is done in a way that the next task activates request scope (with no link to actual original HTTP request) and once done it tears it deactivates the context but deliberately doesn't destroy is hence @PreDestroy callbacks won't execute. I've even added some docs on that to Weld, but I suppose nothing was noted for Arc even though it behaves equally.

If the predestroy callback execute:

• In sequential scenario, you would destroy the bean n-times while still having it active in next step which is just wrong
• In parallel scenario, there is less harm but the bean can operate on some other wider-scope bean (app scoped) and trigger the same logic repeatedly

Furthermore, in parallel scenario you don't really know which propagation step (which thread) is 'eligible' to say "Hey, this is where the request ends!" even if you had the 'shared map' situation.

I've planned a call with @mkouba to discuss possible solutions in Arc.

[FroMage]

Well, I've switched to an implementation that copies the mutable Map and I do get the context properly destroyed when the request context is destroyed by the underlying http request. So it works, really.

[FroMage]

It's destroyed in UndertowDeploymentTemplate when the async request is over, as is proper. If you try to copy the context state instead of propagating the entire mutable request context, I don't think you can implement destroy properly.

[FroMage]

Though I see now it destroys a copy of the request state and not the entire request, so the same problem can happen. I'm not sure why it works in my test then.

[FroMage]

But it's easily fixable as well.

[manovotn]

For the record, this is the bit in Undertow what needs changing as well - https://github.com/quarkusio/quarkus/blob/master/extensions/undertow/runtime/src/main/java/io/quarkus/undertow/runtime/UndertowDeploymentRecorder.java#L489

[manovotn]

A draft of what me and Martin came up with is here - #3243
It basically shares the map but indirectly via an interface so that the map isn't publicly exposed.

[FroMage]

Thanks!