question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Work with ThreadLocal-sensitive Components

See original GitHub issue

Many application trace framework use ThreadLocal to store the call context of a application, like the SLF4j MDC, CAT , and other distributed trace system(which use thread local for trace the context in some async situation).

But the coroutine will be dispatched to a unspecified thread to execute, how can i make the tracing work?

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Comments:10 (7 by maintainers)

github_iconTop GitHub Comments

7reactions
elizarovcommented, Apr 27, 2018

We should really have it out-of-the box in a separate integration module.

5reactions
elizarovcommented, Aug 21, 2018

API in PR #454 now looks like this. In your to use it you have to define your own context element that implements ThreadContextElement interface like this:

// declare thread local variable holding MyData
private val myThreadLocal = ThreadLocal<MyData?>()

// declare context element holding MyData
class MyElement(val data: MyData) : ThreadContextElement<MyData?> {
    // declare companion object for a key of this element in coroutine context
    companion object Key : CoroutineContext.Key<MyElement>

    // provide the key of the corresponding context element
    override val key: CoroutineContext.Key<MyElement>
        get() = Key

    // this is invoked before coroutine is resumed on current thread
    override fun updateThreadContext(context: CoroutineContext): MyData? {
        val oldState = myThreadLocal.get()
        myThreadLocal.set(data)
        return oldState
    }

    // this is invoked after coroutine has suspended on current thread
    override fun restoreThreadContext(context: CoroutineContext, oldState: MyData?) {
        myThreadLocal.set(oldState)
    }
}

The implementation is quite efficient now. Its cost is O(N), where N is the size of the context (number of elements in the context). When a coroutine is resumed on a thread its context is scanned for elements that implement ThreadContextElement and they are given change to update the context of the thread.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Intro to ThreadLocal in Java - Developer.com
We look at the basic concepts behind the ThreadLocal class and how to work with it in the Java programming language. Learn more....
Read more >
Java static code analysis: "ThreadLocal" variables should be ...
ThreadLocal variables are supposed to be garbage collected once the holding thread is no longer alive. Memory leaks can occur when holding threads...
Read more >
ThreadLocal Internal Working - Anmol Sehgal
ThreadLocals are the famous components in any multithreaded environment. To explain it in nutshell, ... Internal Working of Thread Local.
Read more >
Spring Request scope vs java thread-local - Stack Overflow
In code, using ThreadLocal: private static final ThreadLocal<SomeClass> myThreadLocal = new ThreadLocal<SomeClass>(); And for each http request ...
Read more >
Better Performance Through Thread-local Emulation
tion for thread-local emulation, the software and hardware ... Copyrights for components of this work owned by others than.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found