[Question] Does Aedile support ThreadContextElement?

[olaisolheim]

I'm using Caffeine to cache a set of values from a server that refreshes every 60 seconds using refreshAfterWrite and an async reload.

The client that communicates with the server implicitly uses a security token that resides in a ThreadLocal<String> of some other singleton class. This means that when Caffeine uses reload to refresh its values, the security token is not set.

As such, I normally use Kotlin's ThreadContextElement to solve this problem, which configures the coroutine scope to transport the invoking thread's thread locals to any threads created by Kotlin under the current scope:

val valuesFromServer = runBlocking(Dispatchers.IO + CustomThreadContextElement()) {
    val deferredValues = keys.map { async { getServerValue(it) } }
    deferredValues.awaitAll()
}

This is a problem in Caffeine, which is why I was happy to find your library Aedile. :)

However, there does not seem to be a way to have Aedile use the coroutine scope of the code block where the cache.get method is invoked (similar to async above), as I have to specify the scope for Aedile to use when building the cache at class level, where I have no way of accessing the scope where my ThreadContextElement is configured.

If I do not specify the scope, I can see from your code that you create a new scope which is used for the async coroutines. Since these do not use my coroutine scope, the context is lost.

class CachingClient {

    private val cache = Caffeine.newBuilder()
        .refreshAfterWrite(Duration.ofSeconds(60))
        .asLoadingCache<String, String>(
            // can only specify scope here
            { key ->
                // my thread locals are `null` here since this code runs in a new thread
                httpClient.getServerValue(key)
            },
            { key, oldValue ->
                try {
                    // my thread locals are `null` here since this code runs in a new thread
                    httpClient.getServerValue(key)
                } catch (e: Throwable) {
                    oldValue
                }
            }
        )

    fun getServerValue(key: String): String {
        // my thread locals are set on the current thread
        val result = runBlocking(Dispatchers.IO + MyCustomThreadContextElement()) {
            cache.get(key)
        }
    }
}

Is there a way to have cache.get transport its coroutine scope to the internal async operations of Aedile?

[sksamuel]

So to clarify, you want to specify the scope used by the default asLoadingCache coroutine context ?

[olaisolheim]

Thanks for the response. Yes, but not when instantiating the cache at class level.

I see that the current builders allow for me to pass a coroutine scope to the cache when building it, which I'm sure is useful for things like having it use the IO dispatcher. But when building the cache, I cannot find a way to specify that it should use the scope of the call to cache.get, which is where the thread locals can be accessed using this code:

        val result = runBlocking(Dispatchers.IO + MyCustomThreadContextElement()) {
            cache.get(key)
        }

I see that there are some tests that would seem to indicate that this is the default behaviour (code here), but I can't seem to get it working. It's fully possible that I've misunderstood either something with the library or with how Kotlin coroutines work.

[olaisolheim]

I ended up not using Aedile and just using caffeine directly with a custom thread executor that copies the thread locals to a new thread.

private val cache = Caffeine.newBuilder()
        .refreshAfterWrite(cacheRefreshInterval)
        .executor(MyContextPropagatingExecutor)
        .build(object : CacheLoader<CacheKey, CacheResult> { ... }

:

val result = cache.get(CacheKey)

:

object MyContextPropagatingExecutor : Executor {

    override fun execute(command: Runnable) {
        val myThreadLocals = MyThreadLocals.fromCurrentThread()
        Thread {
            val previous = MyThreadLocals.fromCurrentThread()
            try {
                myThreadLocals.updateCurrentThread()
                command.run()
            } finally {
                previous.updateCurrentThread()
            }
        }.start()
    }
}

Thanks for the prompt reply, though. :) I guess you can decide if you wish to keep the issue open to further investigate how this can be solved with Aedile and Kotlin coroutines, or if it should be closed.

[ben-manes]

FYI, usually a refreshAfterWrite without expiration is a misunderstanding. The feature reloads on the next access after the refresh period to support soft/hard ttl. If you want periodic reloading of an unbounded map then that’s a warm replica. The native concurrency package very well already using schedulers, etc.

[sksamuel]

There's not much you can do here. ThreadLocalContextElement is not as powerful as it seems. For example, as the docs state, it doesn't track modifications to thread locals. The context element does not track modifications of the thread-local variable. Basically it sets the thread local when you enter a coroutine to whatever that coroutine should see, and restores it to the previous value when the coroutine releases the thread so the next coroutine using that thread sees the value it should get too.

Even if you had access to the thread local at class init time, the coroutine would be different inside the recompute functions so it wouldn't share the right thread local. You need the the compute/recompute functions to use the same context as the caller to thread.get, but they're designed to run in the background, so there isn't any context to share.

I think this is just a unique edge case. You have thread locals, background scopes and calling scopes, and trying to make the three work together across java-y and kotlin-y stuff is probably just too hacky compared to doing what you did - use Caffeine directly.