Replies: 2 comments 2 replies
-
/cc @FroMage (context-propagation), @geoand (kotlin), @manovotn (context-propagation) |
Beta Was this translation helpful? Give feedback.
0 replies
-
I am not sure if I have understood correctly what you want to achieve. Why do you need the Vert.x context, why not use the Coroutine Context element? Where is the Vertx Context not propagated correctly? Do you have a small reproducer? |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I have some quarkus-based services written in Kotlin with coroutine support, in which I need to propagate some custom context data.
For that reason, I've been using vert.x duplicated context, however it turns out that it's not being properly propagated on coroutines (code sample below).
I've also tried to enhance it using implementation of
org.eclipse.microprofile.context.spi.ThreadContextProvider
, that would pass the context value between threads, but it doesn't affect vert.x duplicated context either (code sample below)I could of course use
InheritableThreadLocal.asContextElement()
, and sync that with vert.x context, however this would require manually wrapping all my service entrypoints withwithContext
block, like so:My question is - what is the correct approach here ? Is there a way to merry vert.x duplicated context with kotlin coroutines, without the use of custom coroutine scope ?
Vert.x based context access:
ThreadContextProvider implementation:
Beta Was this translation helpful? Give feedback.
All reactions