Vertx 100

[Arleen Smelko]

Vertx is a lightweight, high performanceapplication platform for the JVM that's designed for modern mobile, web,and enterprise applications. Vert.x provides a distributed event busthat allows messages to be sent across vert.x instances and clients. Youcan now redirect and persist any vert.x messages to Apache ActiveMQ Artemis and routethose messages to a specified vertx address by configuring Apache ActiveMQ Artemisvertx incoming and outgoing vertx connector services.

From Java Vert.x Event Bus Integration Releases, download vertx-instrumentation-vx.y.z.zip to a temporary directory and unzip it. Copy all 'jar' files to New Relic Java APM agent's 'extensions' folder.

If you encounter any issues with the Java Vert.x Event Bus Integration, please report them on the GitHub repository. Your feedback helps us identify and address issues promptly, ensuring a smooth and reliable monitoring experience for Vert.x applications. Thank you for contributing to the improvement of our integration.

The code developed in this article is available on GitHub. This is part of the "Introduction to Vert.x Series". The code for this post is located in the -developer/introduction-to-eclipse-vertx repository in the post-1directory.

The vertx-maven-plugin is an optional plugin that packages your app and provides additional functionality (documentation is here). Otherwise you can use the maven-shade-plugin or any other packaging plugin. The vertx-maven-plugin is convenient as it packages the application without any configuration. It also provides a redeploy feature, restarting the application when you update the code or the resources.

This is actually our not fancy application. The class extends AbstractVerticle. In the Vert.x world, a verticle is a component. By extending AbstractVerticle, our class gets access to the vertx field, and the vertx instance on which the verticle is deployed.

The start method creates an HTTP server and attaches a request handler to it. The request handler is a function (here a lambda), which is passed into the requestHandler method, and is called every time the server receives a request. In this code, we just reply Hello (Nothing fancy I told you). Finally, the server is bound to the 8080 port. As this may fail (because the port may already be used), we pass another lambda expression called with the result (and so are able to check whether or not the connection has succeeded). As mentioned above, it calls either fut.complete in case of success, or fut.fail to report an error.

The application is started; open your browser to :8080 and you should see the Hello message. If you change the message in the code and save the file, the application is restarted with the updated message.

This is a JUnit test case for our verticle. The test uses vertx-unit, so we configure a custom runner (with the @RunWith annotation). vertx-unit makes easy to test asynchronous interactions, which are the basis of Vert.x applications.

In the setUp method (called before each test), we create an instance of vertx and deploy our verticle. You may have noticed that unlike the traditional JUnit @Before method, it receives a TestContext object. This object lets us control the asynchronous aspect of our test. For instance, when we deploy our verticle, it starts asynchronously, as do most Vert.x interactions. We cannot check anything until it gets started correctly. So, as a second argument of the deployVerticle method, we pass a result handler: context.asyncAssertSuccess(). It fails the test if the verticle does not start correctly. In addition, it waits until the verticle has completed its start sequence. Remember, in our verticle, we call fut.complete(). So it waits until this method is called, and in the case of failures, fails the test.

So, once the async handle is created, we create an HTTP client and emit an HTTP request handled by our application with the getNow() method (getNow is just a shortcut for get(...).end()). The response is handled by a handler. In this function, we retrieve the response body by passing another function to the handler method. The body argument is the response body (as a buffer object). We check that the body contains"Hello" and declare the test complete.

The vertx-maven-plugin is taking care of the packaging and creates the target/my-first-app-1.0-SNAPSHOT.jar file embedding our application along with all the dependencies (including Vert.x itself). Check the size: around 6MB; and this includes everything to run the application.

This Vert.x crash course has presented: how you can develop a simple application using Vert.x; how to test it, package it, and run it. So you now have a great start on the road to building an amazing system on top of Vert.x. Next time we will see how to configure our application. Don't forget that the code from this blog post series is available in this repository.

En particulier, Vert.x permet la cration de serveurs web, permettant notamment une monte en charge trs efficace[citation ncessaire]. Vert.x se pose ainsi en alternative aux conteneurs de servlets tel que dfinis dans la norme Java EE, comme Tomcat ou Jetty.

Vert.x (prononc "Vertex") a t cr par Tim Fox en 2011 alors qu'il travaillait pour VMWare. Lorsqu'il a quitt cette socit en dcembre 2012 pour travailler sur Vert.x chez Red Hat[3], VMWare dtenait les droits sur le code crit par Tim Fox, la marque Vert.x, le logo, ainsi que le groupe Google et le dpt Github[4].

Aprs discussions, il a t dcid en janvier 2013 que le projet rejoindrait la fondation Eclipse[5]. Une proposition de projet a t cr dans ce sens et en aot 2013, Vert.x est devenu un projet de la fondation Eclipse. Le projet est maintenant sous une double licence ASL et EPL[6]. Vert.x est dsormais un sous-projet du projet RT (pour Runtime) de la fondation Eclipse[7].

Vert.x devait initialement s'appeler Node.x, en rfrence Node.js et son aspect polyglotte, mais les risques de conflit juridique avec Joyent, l'entreprise promouvant Node.js, ont finalement pouss le renommer Vert.x.

La version 3.0 prvoit notamment le support du langage Ceylon (des exemples et de la documentation sont dj disponibles sur le site, mais le module Ceylon n'est pas encore intgr la distribution standard), le chiffrement du bus d'vnements, la gnration de donnes mtriques permettant l'intgration des systmes de monitoring et la fourniture d'interfaces avec le bus d'vnements pour Android et iOS, de manire similaire l'interface pour client Javascript vertxbus.js.

Comme Node.js, Vert.x est une implmentation du design pattern reactor. Le fonctionnement de Vert.x est bas sur un composant appel verticle. Par dfaut, chaque verticle n'est instanci qu'une seule fois par cœur d'excution du systme, mais il est possible d'augmenter le nombre d'instance pour une verticle, bien que a ne soit pas recommand. Chaque instance de verticle s'excute toujours dans le mme thread, mais un thread peut excuter des verticles diffrents.Vert.x maintient un pool de threads, appel "event loop pool" pour l'excution des verticles. La taille du pool correspond par dfaut un seul thread par cœur physique disponible dans le systme, ce qui veut dire que chaque cœur du systme va excuter un seul thread, ce qui permet une performance optimale en diminuant les pertes de puissance de calcul dues aux changements de contexte d'excution des diffrents cœurs.Une verticle fonctionne avec une boucle vnementielle (event loop en anglais) grant une file de requtes en entre. Le rle de cette boucle est de lire les requtes et de les traiter de faon non-bloquante.Chaque verticle a son propre classloader, ce qui permet de s'assurer que les verticles ne peuvent pas connaitre l'tat d'une autre verticle, mme pour les attributs statiques.

Un type particulier de verticle, appel working verticles, permet d'excuter des traitements bloquants, ce qui permet des traitements longs et complexes, ainsi que l'utilisation d'outils traditionnels Java, n'ayant pas t conus pour le traitement non-bloquant, comme JDBC, par exemple. Les working verticles peuvent s'excuter dans plusieurs threads sur un mme cœur, la diffrence des autres verticles. Vert.x gre un pool de threads appel "background pool" pour assigner des threads aux working verticles[9].

Les verticles peuvent tre crits en Java, Javascript, CoffeeScript[10], Ruby, Python, Groovy, Scala et Clojure. Il est possible de combiner des verticles crites dans diffrents langages au sein d'une mme application. Le dveloppement en Javascript suit le standard CommonJS.

Le bus vnementiel (Event bus) est le systme de communication principal entre les verticles, chaque verticle tant isole et n'ayant pas connaissance de l'existence des autres. Il est bas sur le principe du passage de messages. Ce bus permet la diffusion d'information suivant plusieurs patterns architecturaux : publication/souscription (un message est reu par tous les abonns), messagerie point point (un seul abonn reoit le message, et les diffrents abonns reoivent des messages tour de rle, suivant le principe du round-robin) et requte/rponse (comme le point point, mais le message contient un handler de rponse). Le bus vnementiel peut s'ouvrir sur des applications Javascript hors de Vert.x l'aide d'un pont utilisant SockJS, en particulier vers des applications clientes, ce qui permet une communication utilisant des websockets, plus directe qu'avec des web services. L'application Javascript doit importer le fichier vertxbus.js afin de pouvoir accder au bus de Vert.x. D'autres moyens d'accs ce bus sont prvus pour la version 3 de Vert.x, notamment des bibliothques C++, ainsi que pour Android et iOS.

Un mode haute disponibilit permet de faire en sorte qu'un verticle victime d'un plantage se relance sur un autre nœud du systme ("automatic failover"). Il est aussi possible de regrouper les nœuds en groupe afin qu'un verticle se relance sur un nœud du mme groupe. On peut galement dfinir un "quorum" de nœuds devant fonctionner dans un groupe pour qu'un verticle puisse y tre dploy.

3a8082e126