Eclipse Vert.x 4 beta 1 released!

We are ex­tremely pleased to an­nounce the first 4.0 beta re­lease of Eclipse Vert.x .

Vert.x 4 is the evo­lu­tion of the Vert.x 3.x se­ries that will bring key fea­tures to Vert.x.

Vert.x Web

Fixed CVE-2020-35217.

SQL client metrics

Vert.x 4 sup­ports met­rics for clients which are crit­i­cal for mon­i­tor­ing ap­pli­ca­tion per­for­mance.

While the ca­pa­bil­i­ties are generic and can apply to any client, each client needs a spe­cific in­te­gra­tion. Ob­vi­ously the SQL client was the per­fect can­di­date in mind for this new fea­ture.

Mi­crom­e­ter met­rics will re­port these met­rics as

  • vertx_sql_queue_pend­ing: num­ber of re­quests sched­uled but not yet ex­e­cuted
  • vertx_sql_queue_time: time spent in queue be­fore pro­cess­ing
  • vertx_sql_pro­cess­ing_pend­ing: num­ber of re­quest being processed
  • vertx_sql_pro­cess­ing_time: re­quests la­ten­cies

A better API for JDBC Client

Our JDBC client will not go away in Vert.x 4, we do rec­kn­og­nize that JDBC is im­por­tant be­cause it sup­ports the most im­por­tant num­ber of data­bases in the ecosys­tem.

When we de­signed the SQL client API we strived a lot to come with the sim­plest and most pow­er­ful API for asyn­cho­nous SQL client.

This re­lease brings an im­ple­men­ta­tion of the SQL client API for JDBC.

The 3.x API se­ries will con­tinue to be sup­ported for the life­time of Vert.x 4.

Event loop affinity

Using Vert.x from a non Vert.x thread is a very com­mon use case we have been sup­port­ing since Vert.x 3.

When you use a Vert.x re­source (like a client) from a non Vert.x thread, Vert.x 3 ob­tains a new event-​loop every­time it hap­pens.

In Vert.x 4 we de­cided to pin the first event loop to the non Vert.x thread. The goal is to pre­vent some data races and also makes rea­son­ning about this eas­ier.

Vertx vertx = Vertx.vertx();

for (int i = 0;i < 4;i++) {
  String msg = "Message " + i;
  vertx.runOnContext(v -> {
    System.out.println(i);
  });
}

Run­ning this with Vert.x 3 will print the 4 lines but they are likely to not be re­ordered, this code could also be run­ning in par­al­lel (that is two dif­fer­ent threads run­ning at the same time on a dif­fer­ent CPU core).

Run­ning this with Vert.x 4 will print the 4 lines in the cor­rect order and al­ways with the same thread. This elim­i­nates some po­ten­tial data races and also al­lows to rea­son about what will hap­pen at run­time.

Vert.x Json Schema supports Draft2019-09

The new vertx-​json-schema mod­ule now sup­ports the lat­est Json Schema Draft2019-09 spec. You can fi­nally play with the new $recursiveRef to build ex­ten­si­ble re­cur­sive schemas and with unevaluatedProperties/unevaluatedItems to de­fine strict schemas. Look at the mod­ule doc­u­men­ta­tion to start using it.

Clustering configuration simplified

In Vert.x 3, clus­ter host was set to localhost by de­fault in EventBusOptions. Con­se­quently, a lot of new users were con­fused about why event bus con­sumers and pro­duc­ers were not able to com­mu­ni­cate even if the un­der­ly­ing clus­ter man­ager was con­fig­ured cor­rectly.

Also, when using the CLI tool or the Launcher class, Vert.x tried to find a host among avail­able net­work in­ter­faces if none was pro­vided with the -cluster-host ar­gu­ment. Some­times, the host cho­sen by the clus­ter man­ager and Vert.x were not the same.

Start­ing with Vert.x 4 beta 1, the clus­ter host de­fault has been re­moved and, if users don’t pro­vide any, Vert.x will ask the clus­ter man­ager which one it picked be­fore try­ing to find one it­self. This ap­plies whether Vert.x is em­bed­ded in any Java pro­gram or started with the CLI tool or with the Launcher class.

So far, only vertx-hazelcast and vertx-infinispan clus­ter man­agers can pro­vide Vert.x with a clus­ter host. When other clus­ter man­agers are used, Vert.x will choose one it­self.

Cluster manager upgrades

vertx-hazelcast has been up­graded to Hazel­cast 4.0.2 and vertx-infinispan to In­fin­is­pan 11.0.1.Final.

Finally

This is the Beta1 re­lase of Vert.x 4, you can of course ex­pect more betas as we get feed­back from the com­mu­nity and fix is­sues that we failed to catch be­fore.

You can also read the mile­stone an­nounces to know more about the over­ral changes:

The dep­re­ca­tions and break­ing changes can be found on the wiki.

For this re­lease there are no Docker im­ages.

The re­lease ar­ti­facts have been de­ployed to Maven Cen­tral and you can get the dis­tri­b­u­tion on Maven Cen­tral.

You can boot­strap a Vert.x 4.0.0.Beta1 project using https://start.vertx.io.

The doc­u­men­ta­tion has been de­ployed on this pre­view web-​site https://vertx-​web-site.github.io/docs/

That’s it! Happy cod­ing and see you soon on our user or dev chan­nels.

Next post

Eclipse Vert.x 3.9.3 released!

Eclipse Vert.x version 3.9.3 has just been released. It fixes quite a few bugs that have been reported by the community.

Read more
Previous post

Eclipse Vert.x 3.9.2 released!

The new Eclipse Vert.x version 3.9.2 has just been released. It includes a few bug fixes, a new reactive DB2 client, and reactive MySQL Client domain socket support.

Read more
Related posts

Things to keep in mind concerning CSRF attacks

Eclipse Vert.x like most frameworks provides an anti-CSRF defense. However, no framework can prevent all attack vectors that exist in the web. Therefore, developers need to be aware of some dangers and common attack vectors concerning CSRF defenses.

Read more

Eclipse Vert.x 4 milestone 5 released!

We are extremely pleased to announce the fifth 4.0 milestone release of Eclipse Vert.x. This release aims to provide a reliable distribution of the current development of Vert.x 4.

Read more

Eclipse Vert.x 4 CR1 released!

The first release candidate of the upcoming Vert.x 4 has just been released. We consider it feature complete and invite the community to test it.

Read more