RFC: Vert.x 4 context model

Vert.x 4 context model

Intro

Vert.x 1 and 2 were designed to have component exclusively to be used from the event-loop thread: using an event-loop API from another thread was simply throwing an exception.

Vert.x 3 has been simplified to allow being used from other threads, a thread can get a reference to a WebSocket and use it to write frames.

Problem

Currently this model is still limited because the underlying component is pinned to an event-loop and most callbacks will be done on this event-loop. This is not an issue per se when the Vert.x model is used, however this is visible in some use cases, e.g sharing a client between several verticles: some client will naturally support it (e.g JDBC client, Mongo client) because they are not event-loop based and will use the calling context to piggy back the result, some will not like HttpClient because it is already associated with an event-loop (usually the event-loop of the Netty channel).

Goals

• Vert.x 4 component can be used from other verticles
• in the future we could extend Vert.x context to allow integration with other kind of contexts, e.g a worker context is already such kind of integration, but it could be an integration with a specific framework using Vert.x

Proposal

Vert.x component should be upgraded so that they make the distinction between the resource context and the caller context.

• when the component is used within the same verticle, then it should work like before because the two contexts will be the same.
• when the component is used from another context, then message passing will be done between the two event loops.

Recently ContextInternal was added a dispatch method that will perform such task:

• when used on the same event-loop this will be a handler call that associate the current thread with the context
• otherwise it performs a runOnContext operation

Components

• Vert.x Core
  • Vert.x HTTP client
    • ☑️ HTTP/1
    • ☑️ HTTP/2
    • ☑️ WebSocket
  • Vert.x HTTP server
    • ☑️ HTTP/1
    • ☑️ HTTP/2
    • ☑️ WebSocket
• ☑️ Vert.x SQL Client

There are more components, usually they should be easy to convert / check when they are not Netty based.

NOTE: currently we have a similar situation with the SockJS handler with HTTP based transports (such as long polling). Such transport can reconnect and use a different event-loop that the initial one.