Problem with PF v2.9.x/v3.x + async caffeine cache + CompletableFuture.join()

[Rotkaf]

Hi,

I've problem with PF v2.9.x/v3.x + async caffeine cache + CompletableFuture.join() work together.

The sample code:

1. Setting some data in cache:

public CompletionStage<Result> setCache() {
	return cache.set(cacheKey, "2000").thenApply(done -> ok());
}

2. Getting data with .join() from cache:

public Result test() {
	String value = getValueFromCache()
			.toCompletableFuture()
			.join()
			.orElse("no value");

	System.out.println("value = " + value);
	return ok(value);
}

public CompletionStage<Optional<String>> getValueFromCache() {
    return cache.get(cacheKey);
}

The problem is that getting value from cache, if set earlier, hangs "forever" (the println is never printed).
However if the value is not set or removed - it doesn't hang.

I've tried this: https://www.playframework.com/documentation/2.9.x/JavaCache#Setting-the-execution-context but with no success:

play.cache.dispatcher = "contexts.blockingCacheDispatcher"
contexts {
  blockingCacheDispatcher {
    fork-join-executor {
      parallelism-factor = 3.0
    }
  }
}

What's maybe can be also interesting that it works perfect with ehcache.
The code also worked in PF v2.8.x.

Moreover, this code works:

public CompletionStage<Result> testCs() {
	return getValueFromCache().thenApply(valueFromCache -> {
		String value = valueFromCache.orElse("no value");
		System.out.println("value CS = " + value);
		return ok("CS " + value);
	});
}

but my real problem is that I have quite big project already (from v2.8) and there is many .join() nested calls
so I can't refactor the project easily :(

Is there any chance I can make the code works?

This is some bug in PF/caffeine or I set something wrong or maybe .join() in PF does not work with caffeine anymore...?

[mkurz]

So yeah this worked with Play 2.8 but now your code deadlocks in Play 2.9 and 3.0...
The code change "causing" this is 6b17ee9#diff-039dc927703c7a9f8f525d7b6cef5b27ae98e93d5fb9489ec84464b731be00c2R222, where I switched the executioncontext of some very lightwight operation to be a Play internal trampline executor. Using trampoline just means that the execution of a task should not happen on another thread (of maybe another thread pool) but the exact same thread that is already executing. The intention is to avoid thread switching for very lightwight things like casting, etc. (like the code referenced), to avoid unnecessary slowdowns. The thing is we do use trampoline not just in the cacheApi now, but we do use and did use it scattered throughout the Play code base.
However, when using trampoline, blocking is highly discouraged, it even says so in the trampoline scaladoc:

playframework/core/play-streams/src/main/scala/play/api/libs/streams/Execution.scala

Lines 24 to 25 in dbcf62d

	* Blocking should be strictly avoided as it could hog the current thread.
	* Also, since we're running on a single thread, blocking code risks deadlock.

In your case, the call to join means that the current thread is waiting for itself now in Play 2.9+, which of course is a deadlock. In Play 2.8 this did work because we did not use trampoline but some other execution context, so a real thread switch did happen and the current thread could actually wait for that thread.

So thinking about it, I am reluctant to revert this change, because, like said, it's meant to speed up things (and question would be which thread pool should we use? why should we revert the use of trampline here but not somewhere else? -> which makes me think that using join could cause problems in all parts of your application)

Morever, looking at your code I would argue your use of join() is wrong here and is not following Play's design principles. I mean I get that you want to wait for a thread to finish, however given the nature of how Play is designed to work, you should not need to call join. Play is designed to be async all the way and blocking is highly discouraged.

Actually you already solved the problem yourself in testCs, which contains the correct code how to return an async computation from your action method.
As alternative, you could use SyncCacheApi instead of AsyncCacheApi, meaning the cache operations are not async, which means you can just continue returning a Result from you action methods.
(What I don't get in your code is why getValueFromCache returns CompletionStage<...> but then you wait for it with join because you have an action method the does not return CompletionStage. That just does not make sense, why do you even use AsyncCacheApi then? Just use SyncCacheApi and then you don't need to call join to wait for a thread...)

You do have to refactor your code a bit and in general avoid blocking with calls to join since you might run into other problems, not just when making use of the cacheapi.