A Simple Checklist for Apache Ignite Beginners

If you are running Apache Ignite for the first time, you might face some difficulties. You have just downloaded Apache Ignite, run it a few times, and got some issues. Mostly, these problems are solved in a similar fashion. Therefore, I decided to create a checklist, which provides recommendations to help you avoid issues in the development environments.

1. Configuration Files

When Ignite starts in standalone mode by executing the ignite.sh|bat  file, Ignite uses the $IGNITE_HOME/config/default-config.xml configuration file. In this situation, to connect to the specified node from the Visor command line console, you should choose the default-config.xml file from the configuration file list. Most of the time, the default- config.xml file is the first file in the list.

You have to run the following command to execute an Ignite node with your own Spring configuration file:

{IGNITE_HOME}/bin/ignite.{bat|sh} FILE_PATH/my-ignite-example.xml

or copy the my-ignite-example.xml file in the $IGNITE_HOME/example/config directory and execute the  ignite.{bat|sh} command as follows:

{IGNITE_HOME}/bin/ignite.{bat|sh} examples/config/my-ignite-example.xml

2. Ports

By default, Ignite uses the following local ports:

If you are using Docker/a virtual machine getting your Ignite node up and running, you should open the above ports to communicate from your host machine.

Portions of this article were taken from the book The Apache Ignite book. If it got you interested, check out the rest of the book for more helpful information. 

3. Logs

Log files are tracking events that happen when running Ignite. A log file is very useful to find out what happened with the Ignite application. If you have encountered a problem, and asked a question in Ignite forums, first of all, you will be asked for the log file. Ignite logging is enabled by default, but there are a few drawbacks. In default mode, Ignite writes not so much logging information’s on the console (stdout). In the console, you see only the errors; everything else will be passed to the file. Ignite log files are located on the $IGNITE_HOME/work/logdirectory by default. Do not erase log files and keep logs as long as possible, as this will be handy for debugging any serious errors.

However, if you want to quickly find out the problems without digging into separates log files, you can execute Ignite in verbose mode.

$ ignite.sh -v

In verbose mode, Ignite writes all the logging information, both on the console and into the files. Note that Ignite runs slowly in verbose modes, and it's not recommended to use this in a production environment.

4. Network

If you encountered strange network errors, for instance, if a network could not connect or could not send the message, most often you've unfortunately been hit by the IPv6 network problem. It can’t be said that Ignite doesn’t support the IPv6 protocol, but at this moment, there are a few specific problems. The easiest solution is to disable the IPv6 protocol. To disable the IPv6 protocol, you can pass a Java option or property to the JVM as follows:

-Djava.net.preferIPv4Stack=true

The above JVM option forces the Ignite to use IPv4 protocols and solves a significant part of the problems related to the network.

5. Ghost Nodes

One of the most common problems that many people encountered several times whenever they launched a new Ignite node. You have just executed a single node and encountered that you already have two server Ignite nodes in your topology. Most often, it may happen if you are working on a home office network and one of your colleges also run the Ignite server node at the same time. The fact is that by default, Ignite uses the multicast protocol to discover and communicate with other nodes. During startup, Ignite search for all other nodes that are in the same multicast group and located in the same subnetwork. Moreover, if it does, it tries to connect to the nodes.

The easiest way to avoid this situation is to configure static IP instead of TcpDiscoveryMulti- castIpFinder. Therefore, use TcpDiscoveryVmIpFinder and write down all the IP addresses and ports to which you are going to connect. These particular configuration helps you to protect from the ghost nodes in a development environment.

6. Baseline Topology 

Ignite baseline topology was introduced in version 2.4.0 and became a convenient way to protect the durability of the data through native persistence. However, what’s wrong with the Ignite baseline topology? To answer that question, let’s imagine the following scenario:

• We have launched a single Ignite node with native persistence enable (data will be written to the disk).
• We activated the cluster because we enable native persistence for the node.
• We have created a REPLICATED cache and loaded some data on it.
• Next, we launched two more nodes and start manipulating with data, insert/delete some data.

At this moment, each node contains the full copy of the data and works well. After a while, we decided to restart one of the nodes. If we stop the very first node from which we start, then everything breaks, and the data is lost. The reason for this strange behavior is the Ignite baseline topology, a set of server nodes that stores persistence data. In the rest of the nodes, data will not be persisted.

A set of the server nodes is determined for the first time at the moment the cluster is activated. So, the rest of the server nodes that you added later will no longer be included in the baseline topology. Thus, in our case, the set of the baseline topology consists of only one server node and this node persists data on disk. Whenever you stop this server node, everything breaks. Therefore, to prevent this surprise, start all the cluster nodes first, and only then activate the cluster.

So, we can point out the following shortlist for the beginners: