Apache Ignite Cluster Manager for Vert.x

This is a cluster manager implementation for Vert.x that uses Apache Ignite.

In Vert.x a cluster manager is used for various functions including:

  • Discovery and group membership of Vert.x nodes in a cluster

  • Maintaining cluster wide topic subscriber lists (so we know which nodes are interested in which event bus addresses)

  • Distributed Map support

  • Distributed Locks

  • Distributed Counters

Cluster managersdo not* handle the event bus inter-node transport, this is done directly by Vert.x with TCP connections.

Vert.x cluster manager is a pluggable component, so you can pick the one you want, or the one that is the most adapted to your environment. So you can replace default Vert.x cluster manager by this implementation.

Using Ignite cluster manager

If the jar is on your classpath then Vert.x will automatically detect this and use it as the cluster manager. Please make sure you don’t have any other cluster managers on your classpath or Vert.x might choose the wrong one.

Alternatively, you can configure the following system property to instruct vert.x to use this cluster manager: -Dvertx.clusterManagerFactory=io.vertx.spi.cluster.ignite.IgniteClusterManager

Using Vert.x from command line

vertx-ignite-3.9.16.jar should be in the lib directory of the Vert.x installation.

Using Vert.x in Maven or Gradle project

Add a dependency to the artifact.

  • Maven (in your pom.xml):

  • Gradle (in your build.gradle file):

compile 'io.vertx:vertx-ignite:3.9.16'

Programmatically specifying cluster manager

You can also specify the cluster manager programmatically. In order to do this just specify it on the options when you are creating your Vert.x instance, for example:

ClusterManager clusterManager = new IgniteClusterManager();

VertxOptions options = new VertxOptions().setClusterManager(clusterManager);
Vertx.clusteredVertx(options, res -> {
 if (res.succeeded()) {
   Vertx vertx = res.result();
 } else {
   // failed!

Configuring cluster manager

Note: Starting with version 2.0, Apache Ignite has introduced a new off-heap memory architecture. All caches use off-heap memory by default. New memory architecture is described in Ignite Virtual Memory article.

Using configuration file

The cluster manager is configured by a file default-ignite.xml which is packaged inside the jar.

If you want to override this configuration you can provide ignite.xml file on your classpath and this will be used instead.

The xml file is a Ignite configuration file and is described in details in Apache Ignite documentation.

Configuring programmatically

You can also specify configuration programmatically:

IgniteConfiguration cfg = new IgniteConfiguration();
// Configuration code (omitted)

ClusterManager clusterManager = new IgniteClusterManager(cfg);

VertxOptions options = new VertxOptions().setClusterManager(clusterManager);
Vertx.clusteredVertx(options, res -> {
 if (res.succeeded()) {
   Vertx vertx = res.result();
 } else {
   // failed!

Discovery and network transport configuration

The default configuration uses TcpDiscoveryMulticastIpFinder so you must have multicast enabled on your network. For cases when multicast is disabled TcpDiscoveryVmIpFinder should be used with pre-configured list of IP addresses. Please see Cluster Configuration section at Apache Ignite documentation for details.

Trouble shooting clustering

If the default multicast configuration is not working here are some common causes:

Multicast not enabled on the machine.

By default the cluster manager is using TcpDiscoveryMulticastIpFinder, so IP multicasting is required, on some systems, multicast route(s) need to be added to the routing table otherwise, the default route will be used.

Note that some systems don’t consult the routing table for IP multicast routing, only for unicast routing

MacOS example:

# Adds a multicast route for
sudo route add -net

# Adds a multicast route for
sudo route add -net

Please google for more information.

Using wrong network interface

If you have more than one network interface on your machine (and this can also be the case if you are running VPN software on your machine), then Apache Ignite may be using the wrong one.

To tell Ignite to use a specific interface you can provide the IP address of the interface to the bean of IgniteConfiguration type using localHost property. For example:

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
 <property name="localHost" value=""/>

When running Vert.x is in clustered mode, you should also make sure that Vert.x knows about the correct interface. When running at the command line this is done by specifying the cluster-host option:

vertx run myverticle.js -cluster -cluster-host your-ip-address

Where your-ip-address is the same IP address you specified in the Apache Ignite configuration.

If using Vert.x programmatically you can specify this using setClusterHost.

Using a VPN

This is a variation of the above case. VPN software often works by creating a virtual network interface which often doesn’t support multicast. If you have a VPN running and you do not specify the correct interface to use in both the Ignite configuration and to Vert.x then the VPN interface may be chosen instead of the correct interface.

So, if you have a VPN running you may have to configure both the Ignite and Vert.x to use the correct interface as described in the previous section.

When multicast is not available

In some cases you may not be able to use multicast as it might not be available in your environment. In that case you should configure another transport using corresponding IP finder, e.g. TcpDiscoveryVmIpFinder to use TCP sockets, or TcpDiscoveryS3IpFinder to use Amazon S3.

For more information on available Ignite transports and how to configure them please consult the Ignite Clustering documentation.

Enabling logging

When trouble-shooting clustering issues it’s often useful to get some logging output from Ignite to see if it’s forming a cluster properly. You can do this (when using the default JUL logging) by adding a file called vertx-default-jul-logging.properties on your classpath. This is a standard java.util.loging (JUL) configuration file. Inside it set:


and also