If the context is associated with a Verticle deployment, this returns the configuration that was specified when the verticle was deployed.
If the context is associated with a Verticle deployment, this returns the deployment ID of that deployment.
Safely execute some blocking code.
Executes the blocking code in the handler blockingCodeHandler using a thread from the worker pool.
When the code is complete the handler resultHandler will be called with the result on the original context
(e.g. on the original event loop of the caller).
A Future instance is passed into blockingCodeHandler. When the blocking code successfully completes,
the handler should call the {@link Promise#complete} or {@link Promise#complete} method, or the {@link Promise#fail}
method if it failed.
The blocking code should block for a reasonable amount of time (i.e no more than a few seconds). Long blocking operations or polling operations (i.e a thread that spin in a loop polling events in a blocking fashion) are precluded.
When the blocking operation lasts more than the 10 seconds, a message will be printed on the console by the blocked thread checker.
Long blocking operations should use a dedicated thread managed by the application, which can interact with verticles using the event-bus or {@link Context#runOnContext}
Safely execute some blocking code.
Executes the blocking code in the handler blockingCodeHandler using a thread from the worker pool.
When the code is complete the handler resultHandler will be called with the result on the original context
(e.g. on the original event loop of the caller).
A Future instance is passed into blockingCodeHandler. When the blocking code successfully completes,
the handler should call the {@link Promise#complete} or {@link Promise#complete} method, or the {@link Promise#fail}
method if it failed.
The blocking code should block for a reasonable amount of time (i.e no more than a few seconds). Long blocking operations or polling operations (i.e a thread that spin in a loop polling events in a blocking fashion) are precluded.
When the blocking operation lasts more than the 10 seconds, a message will be printed on the console by the blocked thread checker.
Long blocking operations should use a dedicated thread managed by the application, which can interact with verticles using the event-bus or {@link Context#runOnContext}
Invoke {@link Context#executeBlocking} with order = true.
Invoke {@link Context#executeBlocking} with order = true.
Get some data from the context.
Get some local data from the context.
Is the current context an event loop context?
NOTE! when running blocking code using {@link Vertx#executeBlocking} from a standard (not worker) verticle, the context will still an event loop context and this will return true.
Is the current context a worker context?
NOTE! when running blocking code using {@link Vertx#executeBlocking} from a standard (not worker) verticle, the context will still an event loop context and this will return false.
The process args
Put some data in the context.
This can be used to share data between different handlers that share a context
Put some local data in the context.
This can be used to share data between different handlers that share a context
Remove some data from the context.
Remove some local data from the context.
Run the specified action asynchronously on the same context, some time after the current execution has completed.
Is the current thread an event thread?
NOTE! This is not always the same as calling {@link Context#isEventLoopContext}. If you are running blocking code from an event loop context, then this will return false but {@link Context#isEventLoopContext} will return true.
Is the current thread a Vert.x thread? That's either a worker thread or an event loop thread
Is the current thread a worker thread?
NOTE! This is not always the same as calling {@link Context#isWorkerContext}. If you are running blocking code from an event loop context, then this will return true but {@link Context#isWorkerContext} will return false.
Generated using TypeDoc
The execution context of a Handler execution.
When Vert.x provides an event to a handler or calls the start or stop methods of a {@link Verticle}, the execution is associated with a
Context.Usually a context is an *event-loop context* and is tied to a specific event loop thread. So executions for that context always occur on that exact same event loop thread.
In the case of worker verticles and running inline blocking code a worker context will be associated with the execution which will use a thread from the worker thread pool.
When a handler is set by a thread associated with a specific context, the Vert.x will guarantee that when that handler is executed, that execution will be associated with the same context.
If a handler is set by a thread not associated with a context (i.e. a non Vert.x thread). Then a new context will be created for that handler.
In other words, a context is propagated.
This means that when a verticle is deployed, any handlers it sets will be associated with the same context - the context of the verticle.
This means (in the case of a standard verticle) that the verticle code will always be executed with the exact same thread, so you don't have to worry about multi-threaded acccess to the verticle state and you can code your application as single threaded.
This class also allows arbitrary data to be {@link Context#put} and {@link Context#get} on the context so it can be shared easily amongst different handlers of, for example, a verticle instance.
This class also provides {@link Context#runOnContext} which allows an action to be executed asynchronously using the same context.