How to transfer scope for nested async processing on a grandchild thread?

[JKomoroski]

When my request thread transfers scope to a child thread thread, then that thread thread attempts to transfer the scope to a grandchild thread it is possible to introduce a deadlock.

Here is the most simple example I could make. It doesn't actually create an injector or resolve request scoped objects but the underlying deadlock is the same.

    @Test
    @Timeout(value = 1, threadMode = ThreadMode.SEPARATE_THREAD)
    void testScopeTransferSupplier() throws Exception {
        String a = UUID.randomUUID().toString();

        Supplier<String> supplier = () -> a;

        try (final RequestScoper.CloseableScope ignored = ServletScopes.scopeRequest(Map.of()).open()) {
            final Callable<String> transferred = ServletScopes.transferRequest(supplier::get);
            final Supplier<String> transferredSupplier = () -> {
                try {
                    return transferred.call();
                } catch (RuntimeException e) {
                    throw e;
                } catch (Exception e) {
                    // should not happen, but required since we converted this to a callable
                    throw new CompletionException(e);
                }
            };
            assertEquals(a, CompletableFuture.supplyAsync(transferredSupplier).join());
        }
    }

What are our options when we have nested async calls that require request scoped objects in our application code?

[xvik]

This deadlock is by design: it prevents using the same scope from multiple threads. Which means you can't open new scope in sub thread while your current scoped action is not closed.

The test itself is not quite correct: ServletScopes.scopeRequest creates a context to simulate "request scope" - you can use request-scoped beans inside this block, but it is not intended to be propagated with ServletScopes.transferRequest.

GuiceFilter (real http scope) is trickier: one scope is created (and opened) directly in GuiceFilter and another NOT OPENED scope in FilterChainInvocation. So when you do ServletScopes.transferRequest it use the latter scope (and so can open it).

You can't use the same scope from multiple threads at the same time, but you can workaround it:

// action for the first thread
final Callable<String> action1 = ServletScopes.transferRequest(...);
// action for the sub-furst thread
final Callable<String> action2 = ServletScopes.transferRequest(...);

// note: both actions share the same context instance

CompletableFuture.supplyAsync(() -> {
     action1.call();
      CompletableFuture.supplyAsync(() -> {
             action2.call();
       }).join();
}).join()

Or you can return the second scope from the first one:

final Callable<Callable<String>> action1 = ServletScopes.transferRequest(() -> {
     // do something and then action for sub-thread
     return ServletScopes.transferRequest(...);
});

// in this case the context instance will also be the same

CompletableFuture.supplyAsync(() -> {
     final Callable<String> action2 = action1.call();
      CompletableFuture.supplyAsync(() -> {
             action2.call();
       }).join();
}).join()

I know it's ugly, but this is the only way I see.

[JKomoroski]

Basically that serializes the requests in the second thread.

What would the issues with creating a new scope be using:

ServletScopes.scopeRequest(Callable<T> callable, Map<Key<?>, Object> seedMap)

In theory, I could resolve all my request scoped variables and open a new scope. Are there locks in that case as well? (assuming my request scoped variables are thread safe)

[xvik]

You should be able to use ServletScopes.transferRequest directly (ServletScopes.scopeRequest would require uneccessary efforts). Just don't wait for other thread inside transferRequest block (you can wait for thread outside of it).

It should be pretty easy to reorganize current logic to meet this condition (only one transferRequest could work at a time (related to one request)).

[JKomoroski]

As an application developer, yes I could refactor the logic and remove the blocks from the code to get that to work, but it is still easy to introduce a deadlock on accident (especially in large codebases).

In my case I'm writing a library to make writing async calls easier without wrapping every return type in CompletableFuture<T>. Documenting how to avoid the deadlock in a library isn't going to be enough for large applications to avoid subtle flows that deadlock.

I am beginning to think the best path forward for me is going to be a migration to Java 25, and utilize ScopedValues, virtual threads, and the structured concurrency preview api.

Have you put any thought into that?

Related Jeps:
https://openjdk.org/jeps/506
https://openjdk.org/jeps/525
https://openjdk.org/jeps/444
https://openjdk.org/jeps/491

[xvik]

In my case I'm writing a library to make writing async calls easier without wrapping every return type in CompletableFuture

I hope your library would be open sourced - I would like to look how you did it

Have you put any thought into that?

Can't say anything here: I did not work with these new java features (and probably will not work until dropwizard 6 or 7, which will rise base java version). Virtual threads have some problems with ThreadLocals (more care required to avoid memory leaks), but it should be ok with current guice api.

Overall guice servlet api is quite outdated and, eventually, it would need to be rewritten (almost sure guice team wouldn't do it). It's on my todo list, but way not in front as it would require a lot of time (same reason why hk2 is not completely removed in guicey yet). Most likely, will start looking when someone hit a blocker because of this (or when I have more spare time).

It would be very interesting to know about your findings, so, if possible, please tell about your eventual solution. Maybe your finidngs will allow improveming guicey too.