Coordinating verticles - The H Developer: News and Features


Coordinating verticles

Verticles can also communicate with each other. In keeping with the asynchronous approach, vert.x uses an event bus to achieve this. The events on the bus are passed to vert.x instances, allowing communication to occur across processes. It is also possible to share some data structures. Parallel access to the state is, however, responsible for the high degree of complexity of concurrent programming. Consequently, options within the framework are severely restricted. In some situations (a cache, for example) such solutions are, however, required. To this end, vert.x provides sets and maps. This is illustrated by the following code:

public class Fanout extends Verticle {
public void start() {
final Set<String> writeHandler =
vertx.createNetServer().connectHandler(new Handler<NetSocket>(){
public void handle(final NetSocket socket) {
socket.dataHandler(new Handler<Buffer>() {
public void handle(Buffer buffer) {
for (String handler : writeHandler) {
vertx.eventBus().send(handler, buffer);
socket.closedHandler(new SimpleHandler() {
public void handle() {

The application accepts a connection on port 1234. Each callback stores the address of the event handler which vert.x automatically registers for a socket in the writeHandler set. The socket outputs all messages to this handler. The application also registers a handler for the socket, which vert.x calls when data is received. This handler sends the data received by the socket to the event bus, specifically to each event handler registered in writeHandler. When a message arrives at a socket, it is thus forwarded to all sockets.

The code explains the use of shared data structures and the event bus. These two elements make it simple to implement even complex applications.

A break with traditional Enterprise Java

Because vert.x represents a complete break with the Java EE (Java Enterprise Edition) model, it has to offer its own runtime environment. As discussed, developers write verticles; these can be run in their own vert.x instance using, for example, the command:

vertx run de.adesso.WebsocketsEcho -cp ../classes/ -instances 2

This starts a new vert.x instance, gives it a classpath and starts two event loops. The application thus utilises two cores.

A developer can also launch a vert.x server and then run verticles on the server. Vert.x has an API for installing and deploying verticles, allowing these processes to be automated. It is also possible to add modules to vert.x. Vert.x includes, for example, a web server module and a MongoDB persister. Busmods are a special type of module which communicate solely via the event bus and are thus more strictly decoupled from the application.

Java EE developers often rue the absence of this kind of server extension concept. The vert.x modularisation concept is a lot simpler than, say, OSGi.


Vert.x utilises the strengths of the JVM as a highly-optimised runtime environment. With its asynchronous approach, its programming model is entirely different to approaches taken elsewhere in the Java ecosystem. This is particularly useful when an application needs to maintain many open connections simultaneously, as WebSockets necessitate. But vert.x applications should also offer good scalability and be very fast. Vert.x thus represents a new alternative to the Java EE programming model and also includes its own runtime environment.

Vert.x is licensed under the Apache licence. The web site offers visitors detailed documentation, as well as a complete tutorial, which nicely illustrates how it is used in practice. The project is being driven largely by Tim Fox, who works for SpringSource/VMware.

Eberhard Wolff is a founding member of the Java Champions, author of many specialist articles and books and a regular speaker at international conferences.

Print Version | Permalink: