DefaultSyncCacheApi randomly throwing massive amounts of Timeout Exceptions

316 views
Skip to first unread message

Ben Developer

unread,
Aug 17, 2017, 3:22:29 PM8/17/17
to Play Framework
Hello,

We're using Play 2.6.3, latest release, and we've begun getting this in our server logs:

Caused by: java.util.concurrent.TimeoutException: null

at java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1771)

at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915)

at play.cache.DefaultSyncCacheApi.blocking(DefaultSyncCacheApi.java:82)

at play.cache.DefaultSyncCacheApi.get(DefaultSyncCacheApi.java:31)


We're injecting the standard SyncCacheApi and the code throwing this error is a simple .get(cacheKey) call to the injected SyncCacheApi.

Does anyone know the cause of this?

Johan Dahlberg

unread,
Aug 18, 2017, 4:13:37 PM8/18/17
to Play Framework
Hi!

I had a similar error with play-redis. The problem for me was that my logic was blocking and that when the result from redis was returned there was no available threads.
Are you doing an database stuff in the default execution context. If so it could be a good idea to take a look at this example of how to do it in another execution context.

https://github.com/playframework/play-java-rest-api-example

/Johan

Ben Developer

unread,
Sep 1, 2017, 4:37:51 PM9/1/17
to Play Framework
I do think we are doing it in the default context. We simply have public Result methods in our controllers that then call injected Repositories...

But sometimes it even throws timeout exceptions on Cache.set()...How?/Why?

Any more insight is appreciated.

Johan Dahlberg

unread,
Sep 1, 2017, 5:37:28 PM9/1/17
to Play Framework
I sent you a link in the previous response to an example on how to use a different execution context for the DB code. Have you looked at that example?

Cache.set probably uses changes threads and timeouts when waiting for a thread to be available in the default pool.

/Johan
--
You received this message because you are subscribed to a topic in the Google Groups "Play Framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/play-framework/HEJrWxPapDg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/04db2394-65f8-4810-a71e-43df4b2bfe04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ben Developer

unread,
Sep 2, 2017, 10:43:10 AM9/2/17
to Play Framework
Yes, took a look at it. It 1) Seems overly complex and 2) Would be a monstrous task of migrating over 500 Controllers to this new format. The Play documentation tells us that using public Result methods in your Controllers already act  non-blocking so I'm not too sure why it's an issue. Also, if DB is using up thread pools then why is it timing out on Cache.get / Cache.set? There's no DB read/write in order to read/write from the Cache since it's memory-based...

Do we need to tweak the akka http parallelism and thread pool configs? I don't think we had this issue when we were using Play 2.5 running Netty instead of AkkaHttp. 

R.M.

unread,
Sep 5, 2017, 8:23:08 AM9/5/17
to Play Framework
There's something wrong with SyncCacheApi in 2.6.3: https://github.com/playframework/playframework/issues/7774

I recommend using 2.6.2.
Reply all
Reply to author
Forward
0 new messages