Fre­quently asked ques­tions

The logActivity option is enabled, but nothing is logged

Most Vert.x net­work clients or servers have a logActivity op­tion which en­ables net­work ac­tiv­ity log­ging. When ac­tive, Netty’s pipeline is con­fig­ured for log­ging on Netty’s log­ger, at DEBUG level

This is why switch­ing on the logActivity op­tion is not enough. You also have to set the io.netty.handler.logging.LoggingHandler log­ger to DEBUG level in your log­ging frame­work con­fig­u­ra­tion.

When Vert.x is clustered, what happens to event-bus messages if a node crashes?

When you send a mes­sage on the event-​bus, it is sent to the re­cip­i­ent’s node and stored in mem­ory until it is processed. It is not per­sisted to disk or a data­base.

Con­se­quently, if the re­cip­i­ent’s node crashes be­fore the mes­sage is processed, the mes­sage is lost.

If it’s not pos­si­ble to tol­er­ate loss of some mes­sages, there are a few op­tions in­clud­ing:

  • idem­po­tent retry when send­ing fails with an error
  • asyn­chro­nous ac­knowl­egde­ment

Oth­er­wise, con­sider using a full-​fledged broker-​based mes­sag­ing sys­tem like Apache Ac­tiveMQ or Rab­bitMQ.

Vert.x has clients for such so­lu­tions: Vert.x AMQP Client, Rab­bitMQ Client for Vert.x or Vert.x-​Stomp.

Why doesn't my event-bus consumer pickup messages sent previously?

When you pub­lish a mes­sage on the event-​bus, it is sent to all nodes hav­ing one or more con­sumers reg­is­tered for the cor­re­spond­ing mes­sage ad­dress. It is not per­sisted to disk or a data­base.

Con­se­quently, new con­sumers on ex­ist­ing nodes or nodes join­ing the clus­ter later will not re­ceive this mes­sage.

If you need this fea­ture, con­sider using a full-​fledged broker-​based mes­sag­ing sys­tem like Apache Ac­tiveMQ or Rab­bitMQ.

Vert.x has clients for such so­lu­tions: Vert.x AMQP Client, Rab­bitMQ Client for Vert.x or Vert.x-​Stomp.

How to use the JVM built-in address resolver?

By de­fault, Vert.x re­lies on a non-​blocking ad­dress re­solver in­stead of the JVM built-​in one. For most users this is trans­par­ent but the non-​blocking re­solver is less ma­ture and may not work in some en­vi­ron­ments.

In this case, please file an issue on the Vert.x core repos­i­tory.

As a workaround, you can switch the non-​blocking re­solver off and fall­back to the JVM built-​in one. To do so, start the JVM with the vertx.disableDnsResolver sys­tem prop­erty set to true:

-Dvertx.disableDnsResolver=true