If you are interested in reactive, non-blocking, and asynchronous Java development, you are likely familiar with Eclipse Vert.x. The project started in 2011 and successfully moved to the Eclipse Foundation in 2013. Since then, Vert.x has undergone nine years of rigorous development and grown into a thriving community. It is one of the most widely used reactive frameworks, with support for multiple extensions, including extensions for messaging or streaming with Kafka or Artemis, developing applications with gRPC and GraphQL, and so much more.
The Red Hat build of Eclipse Vert.x 4.0 is now generally available. This release improves Vert.x's core APIs and handling. Developers who migrate can expect enhancements to futures and promises, distributed tracing, and deployment on Red Hat OpenShift. In this article, I introduce these updates and offer tips for migrating and deploying your Eclipse Vert.x 4.0 applications on OpenShift.
Note: Please see the Red Hat build of Eclipse Vert.x 4.0 migration guide for a detailed introduction to migrating from Vert.x 3.x to Vert.x 4.0.
The <Future> is here!
Future is an AsyncResult<T> that you can use to create asynchronous operations in Vert.x 4.0. Every asynchronous method returns a Future object, success or failure, as the result of a call:
FileSystem fs = vertx.fileSystem();
Future<FileProps> future = fs.props("/my_file.txt");
future.onComplete((AsyncResult<FileProps> ar) -> {
if (ar.succeeded()) {
FileProps props = ar.result();
System.out.println("File size = " + props.size());
} else {
System.out.println("Failure: " + ar.cause().getMessage());
}
});
If you prefer to use callbacks and get a Handler back, Vert.x 4.0 still implements props, as shown here:
FileSystem props(String path,Handler<AsyncResult<FileProps>> handler)
Developers migrating from Vert.x 3.x to Vert.x 4.0 can also use Future with callbacks:
WebClient client = WebClient.create(vertx);
HttpRequest request = client.get("/resource");
Future<HttpResponse> response = request.send();
response.onComplete(ar -> {
if (ar.succeeded()) {
HttpResponse response = ar.result();
} else {
Throwable failure = ar.cause();
}
});
Error handling is more straightforward with futures than with callbacks. You don't need to track yourself back into each callback, and you can handle a failure just once, at the end of a composition. Futures also let you compose asynchronous events in parallel or sequentially. All in all, this feature greatly simplifies application programming with Vert.x.
Promises
A promise represents the writable side of an action that may or may not have yet occurred. Each promise has a future() method, which returns a Future for the given promise. You can use promises and futures together to get a notification of completion. The following example shows HttpServerVerticle using a promise.
package com.example.starter;
import io.vertx.core.AbstractVerticle;
import io.vertx.core.Promise;
public class MainVerticle extends AbstractVerticle {
@Override
public void start(Promise<Void> startPromise) throws Exception {
vertx.createHttpServer().requestHandler(req -> {
req.response()
.putHeader("content-type", "text/plain")
.end("Hello from Vert.x!");
}).listen(8888, http -> {
if (http.succeeded()) {
startPromise.complete();
System.out.println("HTTP server started on port 8888");
} else {
startPromise.fail(http.cause());
}
});
}
}
In this case, the method returns the Future associated with a promise. We use the Future to send a notification when the promise has been completed and retrieve its value. Furthermore, a promise extends Handler<AsyncResult<T>> so that we can use it as a callback.
Note: Before migrating your applications to Eclipse Vert.x 4.0, check for deprecations and removals. The compiler will generate a warning when you use a deprecated API.
Distributed tracing
Many components in a modern, distributed software application have their own operations lifecycle. The challenge is to trace various events and correlate that information across components. Tracing lets us understand the state of the system and how well the system adheres to key performance indicator metrics (KPIs). To find out how many people are getting help in a disaster-rescue effort, for example, we must correlate and trace data in a distributed software system. We can use that information to evaluate whether the software is meeting our business requirements.
Distributed tracing lets us visualize and understand the chain of events and flows in an interaction between software applications. For distributed tracing in microservices environments, we can use Vert.x 4.0 with Jaeger, an OpenTracing client that is part of the Cloud Native Computing Foundation.
Note: See the Red Hat OpenShift guide to configuring and deploying Jaeger for instructions to install Jaeger.
Once we have Jaeger installed, we can use the following Vert.x components to log traces:
- HTTP server and HTTP client
- Eclipse Vert.x SQL client
- Eclipse Vert.x Kafka client
Each of these components implements the following TracingPolicy:
- PROPAGATE: The component reports a span in the active trace.
- ALWAYS: The component reports a span in the active trace or creates a new active trace.
- IGNORE: Ignores tracing for the component in question.
Here's an example of a simple tracing policy implementation:
HttpServer server = vertx.createHttpServer(new HttpServerOptions() .setTracingPolicy(TracingPolicy.IGNORE) );
See the Vert.x Opentracing examples repository for a more detailed tracing example with Vert.x and Jaeger.
Metering labels for OpenShift
You can now add metering labels to your Eclipse Vert.x applications running on OpenShift. Customers use the labels to track deployments they have subscribed to follow. Eclipse Vert.x uses the following metering labels:
- com.redhat.component-name: Vert.x
- com.redhat.component-type: application
- com.redhat.component-version: 4.0.0
- com.redhat.product-name: "Red_Hat_Runtimes"
- com.redhat.product-version: 2021/Q1
See the OpenShift 4.6 documentation for more about metering labels.
Deploying Eclipse Vert.x applications to OpenShift
Eclipse JKube is a collection of plug-ins and libraries for building container images using Docker, Jib, or source-to-image (S2I) build strategies. Unlike its predecessor, Fabric8, Eclipse JKube eases Java development on Kubernetes and OpenShift. Developers can focus on creating applications without getting into details, such as creating manifests.
Eclipse JKube includes manifests as part of the Maven build, then generates and deploys them at compile time. The JKube plug-in generates resource manifests for you automatically, which you can apply afterward. Here's an example of how to run an application on OpenShift with Eclipse JKube:
# The following commmands will create your OpenShift resource descriptors. mvn clean oc:resource -Popenshift # Starting the S2I build mvn package oc:build -Popenshift # Deploying to OpenShift mvn oc:deploy -Popenshift
See this sample project using Eclipse JKube plug-ins for more details.
Packaging and deployment
You can now package and deploy your applications to OpenShift with Open Container Initiative (OCI)-compliant Universal Base Images for Red Hat OpenJDK 8 and 11 on Red Hat Enterprise Linux 8.
Additionally, the Vert.x vertx-web-client.js is now published in the NPM repository and no longer available as a Maven artifact. You can access the client from @vertx/eventbus-bridge-client.js.
New to reactive programming?
If you are new to reactive programming, you can use self-paced scenarios to learn and experiment with Vert.x or learn about other technologies within Red Hat Runtimes. Each scenario provides a preconfigured Red Hat OpenShift instance that is accessible from your browser without any downloads or configuration.
For developers who prefer to dive deep, I recommend reading Vert.x in Action by Julien Ponge.
Get the Red Hat build of Vert.x 4.0
Support for Eclipse Vert.x is available to Red Hat customers through a Red Hat Runtimes subscription. Red Hat's runtime support is scheduling according to the Red Hat product update and support lifecycle.
If you are new to Eclipse Vert.x and would like to learn more, go to our live learning portal for a guided tutorial, or see the product documentation for technical details. You can also check the supported configurations and component details for Eclipse Vert.x on Red Hat Runtimes, and see the migration guide for a detailed introduction to migrating from Eclipse Vert.x 3.x to Vert.x 4.0.
Last updated: January 20, 2021