eclipse-vertx
Local context data overhaul
Define the use case and expectations for local context data in Vert.x 5 in order to improve performance and reliability.
Ideally the local context data storage should be a plain map (not concurrent) and always accessed by the context thread.
Currently sometimes local context data can be accessed concurrently from multiple threads (e.g execute blocking in https://github.com/reactiverse/reactiverse-contextual-logging) and we should find a way to avoid that.
So besides the reactiverse-contextual-logging, we should determine what are the current usage of the feature to best address this in Vert.x 5.
Interesting. Have you captured somewhere the problems we need to address?
Just wanted to write down a few notes of my own.
The duplicated context is easy to access concurrently in pure Vert.x (a simple example). It is also heavily used in Quarkus to store "request-local" data (such as the CDI request context; I'm sure @cescoffier would be able to provide a more exhaustive list), and "requests" in Quarkus easily jump across threads.
I believe we should expose an API that can easily be used in a "concurrency-safe" manner (for example, instead of a get/put pair, expose something like computeIfAbsent, but with a better name :-) ). It might also be useful for the values in the duplicated context to be able to react to the context destruction, if there's such a thing (but this is hard, since we don't control the destruction logic, and it might block or be otherwise not nice).
@tsegismont updated the description, I created the issue during the committers hangout.
I expect more concurrent access to the duplicated context with virtual threads coming.
the question is : is that expected ?
one idea I have in mind is to have a thread local based API approach where the context thread defines an entry point in the context data storage (e.g a map in a map) the root map is not concurrent but the sub map can be.
We (BlueMind) are using duplicatedContext / local context data to store information about the user logged in and such, in particular with NetServer. Currently it's very confusing to have a "per thread context" but not always a duplicated context on requests handlers.
We must wrap the connectHandler with a runOnContext and pass this context down to all the data handlers. Was a painfull / very confusing experience, because nothing prevents from using an eventloop context without knowing (and having the wrong data in the wrong thread).
The "reactiverse vertx logging" lib is great, but don't check anything about context at all like I just explained. So it "works" in http servers because vert.x does setup handlers with context.dispatch(). But if you use NetServer, it's fully broken without creating / passing the duplicated context manually
we could have a duplicated per NetSocket in TCP server I think, it has never been brought up before.