Asynchronous programming using Vert.x and building high performance applications .

The advent of building scalable applications has seen a lot of transition from the use of the use of servlets in Java world to using modern heavy frameworks written on top of JVM like Vert.x and Spring .

Overview

Vert.x is a project started in 2011 by Tim Fox. It is still an official Eclipse Foundation project but led by Red Hat which sees Vert.x as a strategic project.

Vert.x is a framework based on the JVM allowing developers to implement autonomous components. These components communicate together in a weakly-coupled way by sending messages over an Event Bus.

Vert.x offers a polyglot approach because developers are free to implement their components among a list of languages: Java, JavaScript, Groovy, Ruby, and Ceylon.

Likewise, Vert.x offers functionalities for implementing reactive applications based on a non-blocking and callback approach.

Vert.x is often compared as the Node.js for the JVM but we will see the main differences between both frameworks.

Reactor pattern and event loop

As implemented and popularized in Node.js, Vert.x is based upon the Reactor pattern.

The Reactor pattern is a solution:

• To handle 
• Based upon a synchronous and blocking 
• Dispatching

A handler is generally implemented to manage operations such as I/O, database connection, HTTP request etc…

This pattern is often used to offer a solution to the C10k problem. This problem might be described very simply: how can a server handle ten thousand connections at the same time?

In such conditions, the classical approach by creating one dedicated thread per request is no longer possible due to physical and/or OS limitations (way too much thread context switching for instance).In comparison, the Reactor pattern offers a model with a single-threaded event loop.

Yes. One thread to manage 10k connections. If you are not familiar with such concepts, this is pretty disruptive, isn’t it?One thread to manage incoming events and dispatch them to asynchronous handlers.

The Vert.x approach is slightly different though. Let’s imagine now you want to scale-up your machine by adding more CPU cores. If you keep one single thread, you will not benefit from these new resources.

With Node.js though you can bypass this limitation usually by implementing one process per core.

In comparison, Vert.x allows you to configure and define the number of instantiated event loops. This is clearly a lovely and powerful option. A best practice to boost as most as possible the performance of your application is to set up as many instances as the number of CPU cores available.

Verticle model

As mentioned in the overview, Vert.x proposes a model based upon autonomous and weakly-coupled components. This type of component is called in Vert.x a Verticle and can be written in the different languages we have seen. Each verticle has its own class loader.

It is not mandatory to develop Vert.x applications based upon verticles but it is strongly recommended though to adopt this model.

A verticle is basically an object implementing two methods: start() and stop().There are three different types of verticles:

• Standard
• Worker
• Multi-threaded worker
• Send a finite number of 
• Create a finite number of 
• Designate the behavior to be used for 

Event Bus

The last core concept is the Event Bus. As you can imagine, the Event Bus is the support for exchanging messages between the different verticles in a weakly-coupled fashion.

Each message is sent to a logical address. For example: customer.create

The event bus supports the two standard pattern types: point-to-point and publish / subscribe. With point-to-point pattern, you can also manage to implement request-reply if the recipient must reply to the initial message.

One important thing to understand, the event bus implements only best-effort delivery.It means there is no way to manage guaranteed delivery by storing for instance messages on the disk. So there are true possibilities to lose messages.Likewise, there is no capability to implement durable subscribers. It means that if a consumer is not connected to the Event Bus when a message is published, it will never be able to retrieve it.

Within your Vert.x application, the Event Bus may be the standard for synchronous and asynchronous exchanges without having to guarantee the delivery.Otherwise, you should use a third-party messaging middleware.

If your Vert.x application runs on a single JVM node, there is no physical channel. It remains simply a messaging endpoint on-heap.If your application is clustered, an event bus endpoint is available through a TCP channel. But this logic remains invisible for the developer. There is no difference in the way you are going to use the send/publish API. Vert.x manages that for you.