Deploy multiple instances of a verticle with DeploymentOptions.setInstances(n), then coordinate them through Vert.x’s event bus. Use request/reply when one consumer should handle a request, and publish/subscribe when every interested consumer should receive an event. Keep ordinary verticle handlers non-blocking; move blocking work to a worker verticle or executeBlocking.
Deploy multiple instances of a verticle
A verticle instance is an execution unit managed by Vert.x. To run several instances of the same verticle, set the instance count in DeploymentOptions when deploying it. This is the standard way to scale a verticle across available cores; it does not, by itself, guarantee a particular throughput improvement. Measure your application under its expected workload before choosing a count. See the Vert.x 4.4.9 Core documentation.
public class ApiVerticle extends AbstractVerticle {
@Override
public void start() {
vertx.eventBus().consumer("orders.create", message -> {
// Keep this handler non-blocking.
message.reply("accepted");
});
}
}
public class MainVerticle extends AbstractVerticle {
@Override
public void start() {
DeploymentOptions options = new DeploymentOptions().setInstances(4);
vertx.deployVerticle(ApiVerticle.class.getName(), options)
.onSuccess(id -> System.out.println("deployed " + id))
.onFailure(Throwable::printStackTrace);
}
}The example requests four instances; that is an application choice, not a documented optimal value. When multiple instances register consumers on the same event-bus address, Vert.x can distribute messages among those consumers. Each instance still has its own context and local state. Check the EventBus behavior and deployment overloads against the exact Vert.x version pinned by your project, because method signatures and failure details can vary.
Choose the right event-bus communication pattern
The event bus is the normal way for verticles to communicate. Give addresses stable, meaningful names and make message payloads explicit and versionable. Pass data in messages rather than depending on shared mutable objects or in-memory object identity across verticle boundaries.
Request/reply for one handler and a response
Use request when one consumer should handle an operation and the sender needs a result or failure. For example, a sender can request orders.create; the consumer registered at that address processes the request and replies when it has a result. This suits service-like operations with a clear owner. The EventBus documentation describes sending and replying to messages.
Publish/subscribe for independent reactions
Use publish for an event such as orders.created when every consumer registered for that address should receive it. This is useful when independent verticles need to react to the same event without the publisher selecting each recipient.
Rank #2
Multiple consumers on one address
If several instances of a verticle register a consumer at the same address, messages can be distributed among the consumers, allowing the instances to share work. That is different from publishing an event, where every registered subscriber should receive it. Distribution and failure semantics should be verified for the EventBus API version you use.
Keep event-loop handlers non-blocking
Handlers associated with a standard verticle run on its event-loop context. This makes instance-local state convenient, but a blocking file, database, or network call in a handler can stall that event loop and delay other work on it. Vert.x’s Context API documentation explains the context model.
Free tools Windows power users keep installed
One-click scans. No signup required.
Avoid coordinating instances by mutating shared state. Prefer event-bus messages for inter-verticle coordination, and use an external shared store when the data must be shared or durable beyond an individual instance.
Move blocking work to a worker
Worker verticles
A worker verticle runs using a thread from the worker pool rather than an event-loop thread. Deploy one with new DeploymentOptions().setWorker(true) when its work is blocking. Vert.x guarantees that a single worker-verticle instance is not executed concurrently by multiple threads, although successive invocations may run on different worker-pool threads. Do not assume thread identity is fixed over the instance’s lifetime. See the Vert.x Core worker-verticle documentation.
Rank #4
executeBlocking
Use vertx.executeBlocking to move a blocking operation off the event loop. Vert.x 4 removed the multithreaded worker-verticle deployment option; the migration guidance directs users to executeBlocking instead. Choose ordered or unordered execution based on whether work must preserve ordering or may run concurrently. See the Vert.x 4 migration guide.
Handle deployment and shutdown asynchronously
Deployment is asynchronous: calling deployVerticle does not itself mean startup has finished. Handle both success and failure, and retain the deployment ID returned on success when you need to stop that deployment later. Undeployment is asynchronous too, so handle its completion as part of controlled shutdown. Verticles can also have asynchronous startup and stop logic; rely on the completion signals rather than assuming those lifecycle steps are immediate. See the deployment and lifecycle documentation.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Best Value
Make the design choice against your workload
Before choosing instance counts or communication patterns, decide which execution and delivery behavior the application needs. The Vert.x primitives establish how execution and messaging work, but they do not provide application-specific throughput figures.
- Execution: use event-loop contexts for short, non-blocking handlers and workers for blocking operations.
- Message semantics: use request/reply for one handler and a response, or publish/subscribe when all interested consumers should receive the event.
- Scaling: deploy more instances when you want multiple consumers sharing work; select the count through workload testing rather than assuming more instances always improve performance.
- State: keep instance-local mutable state local, pass coordination data in messages, and use an external store when state must be shared or durable.
- Ordering and load: account for ordering and back-pressure requirements when choosing how messages and blocking tasks are processed.
- Lifecycle: handle asynchronous deployment failures and retain deployment IDs for orderly undeployment.
The references cited here cover Vert.x 4.4.9 deployment and event-bus concepts, the 4.5.20 Context API, and the Vert.x 3-to-4 migration. Confirm APIs and behavior against your project’s pinned version before applying version-specific code.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
