Vert.x — Cheat Sheet

Tags: vertx, reactive, java, event-loop, asynchronous, distributed-systems

Level: intermediate

TL;DR: Eclipse Vert.x is an event-driven, non-blocking reactive toolkit for the JVM built on Netty. Crucial rule: never block the event loop; offload synchronous work to worker verticles or executeBlocking.

Key concepts

Event-driven, non-blocking toolkit running on top of Netty.

Polyglot execution supporting Java, Kotlin, Groovy, and JavaScript.

Concurrency model based on actor-like units of deployment called verticles.

Multi-reactor pattern assigns independent event loops to available CPU cores.

Gold rule: never block the event loop thread under any circumstance.

Synchronous blocking tasks execute via worker verticles or executeBlocking.

Event bus provides distributed publish-subscribe, point-to-point, and request-response messaging.

Native reactive streams support backpressure handling across data pipelines.

Lightweight footprint suitable for high-throughput, low-latency microservices.

Typical questions and ready answers

Q: How does Vert.x differ from traditional thread-per-request frameworks like Spring MVC?R: Vert.x uses a non-blocking multi-reactor model where a few event loops handle thousands of concurrent connections, drastically reducing thread overhead and context switching.

Q: What happens if you run blocking I/O on an event loop thread?R: It stalls the entire event loop, freezing all concurrent requests assigned to that loop until the blocking operation completes.

Q: How do you safely run legacy JDBC or blocking computations in Vert.x?R: I wrap blocking calls inside vertx.executeBlocking() or deploy the handling logic as a dedicated worker verticle with a separate worker thread pool.

Q: What messaging patterns does the Vert.x Event Bus support?R: It supports point-to-point sending (send), publish-subscribe broadcasting (publish), and asynchronous request-reply messaging (request).

Pitfalls and common mistakes

Executing thread sleeps, blocking locks, or synchronous database calls directly on the event loop.

Verticle state sharing via static mutable state instead of message passing.

Unhandled failures in asynchronous handlers leading to silent request timeouts.

Neglecting backpressure when reading fast streams into slower downstream consumers.

Over-allocating worker thread pool threads, increasing memory usage and context-switch latency.

Snippets and commands

// Basic HTTP server deployment on event loop
Vertx vertx = Vertx.vertx();
vertx.createHttpServer()
  .requestHandler(req -> req.response().end("Hello from Vert.x"))
  .listen(8080);

Java

// Offloading blocking task away from event loop
vertx.executeBlocking(() -> {
  // Legacy blocking operation
  return blockingDatabaseCall();
}).onSuccess(result -> {
  // Back on event loop
  System.out.println("Result: " + result);
}).onFailure(Throwable::printStackTrace);

Java

// Event Bus point-to-point and consumer
vertx.eventBus().consumer("orders.process", msg -> {
  msg.reply("Processed: " + msg.body());
});

vertx.eventBus().request("orders.process", "Order #1234")
  .onSuccess(reply -> System.out.println(reply.body()));

To review

[ ] Multi-reactor pattern and thread allocation tuning

[ ] Distributed event bus clustering with Hazelcast or Infinispan

[ ] Reactive SQL clients (pg-client, mysql-client) with connection pooling

[x] Basic verticle lifecycle: deploy, start, and stop hooks

[x] executeBlocking error handling and worker thread configurations

References

Eclipse Vert.x Official Documentation (vertx.io/docs)

Reactive Manifesto (reactivemanifesto.org)

Jarvis Interviews
Jarvis