News

"The Apache Ignite Book" distribution channels

From this year we have added a few more channels for distributing our book "The Apache Ignite book", which is considered as one of...

Monday

Monitoring Apache Ignite Cluster With Grafana (Part 1)

Apache Ignite is built on JVM and not a set-it-and-forget-it system. So, like other distributed systems, it requires monitoring for acting on time. However, Apache Ignite provides a web application named Ignite Web Console to manage and monitor the cluster, but it's not enough for system monitoring. You can also use JConsole/VisualVM for monitoring an individual Ignite node and a small number of Ignite nodes. Monitoring an Ignite cluster over 5 nodes by VisualVM or JConsole is unrealistic and time-consuming. Also, JMX does not provide any historical data. So, it is not recommended for production environments. Nowadays, there are a lot of tools available for system monitoring. The most famous of them are:
In this article, we cover the Grafana for monitoring Ignite clusters and provide step-by-step instructions to install and configure the entire stack technology.
Grafana is an open source graphical tool dedicated to query, visualize, and alert all your metrics. It brings your metrics together and lets you create graphs and dashboards based on data from various sources. Also, you can use Grafana to display data from different monitoring systems like Zabbix. It is lightweight, easy to install, easy to configure, and it looks beautiful.
Before we dive into the details, let’s discuss the concept of monitoring large-scale production environments. Figure 1 illustrates a high-level overview of how the monitoring system looks in production environments.
Figure 1.
In the above figure, data such as OS metrics, log files, and application metrics are gathering from various hosts through different protocols like JMX, SNMP into a single time-series database. Next, all the gathered data is used to display on a dashboard for real-time monitoring. However, a monitoring system could be complicated and vary in different environments.
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.
Let’s start at the bottom of the monitoring chain and work our way up. To avoid a complete lesson on monitoring, we will only cover the basics along with what the most common checks should be done as they relate to Ignite and it's operation. The data we are planning to use for monitoring are:
  • Ignite node Java Heap.
  • Ignite cluster topology version.
  • Amount of server or client nodes in the cluster.
  • Ignite node total up time.
The stack technologies we use for monitoring the Ignite cluster comprise three components: InfluxDB, Grafana, and jmxtrans. The high-level architecture of our monitoring system is shown in the figure below.
Figure 2
Ignite nodes does not send the MBeans metrics to the InfluxDB directly. We use jmxtrans, which collects the JMX metrics and send to the InfluxDB. Jmxtrans is lightweight and running as a daemon to collect the server metrics. InfluxDB is an open-source time series database developed by InfluxData. It is written in Go and optimized for fast, high-availability storage and retrieval of time series data in fields such as operations monitoring and application metrics.
Next, we install and configure InfluxDB, Grafana, and jmxtrans to collect metrics from the Ignite cluster. We also compose a custom dashboard in Grafana that monitors Ignite cluster resources.
Prerequisites. To follow the instruction to configure the monitoring infrastructure, you need the following:
Name Version
OS MacOS, Windows, *nix
InfluxDB 1.7.1
Grafana 5.4.0
jmxtrans 271-SNAPSHOT
Step 1. The data store for all the metrics from the Ignite cluster will be Influx. Let’s install the InfluxDB first. I am using MacOS, so I will use Homebrew to install InfluxDB. Please visit the InfluxDB website and follow the instructions to install for other operating systems like Windows or Linux.
brew install influxdb
After completing the installation process, launch the database by using the following command:
influxd -config /usr/local/etc/influxdb.conf
InfluxDB running on http://localhost:8086 and provides REST API for manipulating the database objects by default. Also, InfluxDB provides a command line tool named influx to interact with the database. Execute the influx shell script on another console which starts the CLI and automatically connects to the local InfluxDB instance. The output should look as follows:
influx
Connected to http://localhost:8086 version v1.7.1 InfluxDB shell version: v1.7.1
Enter an InfluxQL query
A fresh install of InfluxDB has no database, so let’s create a database to store the Ignite metrics. Enter the following Influx Query Language (a.k.a InfluxQL) statement to create the database.
create database ignitesdb
Now that the ignitesdb database is created, we can use the SHOW DATABASES statement to display all the existing databases.
show databases
name: databases name
----
_internal ignitesdb
Note that the _internal database is created and used by InfluxDB to store internal runtime metrics. To insert or query the database, use USE <db-name> statement, which will automatically set the database for all future requests. For example:
USE ignitesdb
Using database ignitesdb
That's enough for now. In the next part of this article, we will install and configure Grafana, jmxtrans to monitor the Ignite cluster. Stay tuned!

Sunday

8 things every developer should know about the Apache Ignite caching

Any technology, no matter how advanced it is, will not be able to solve your problems if you implement it improperly. Caching, precisely when it comes to the use of a distributed caching, can only accelerate your application with the proper use and configurations of it. From this point of view, Apache Ignite is no different, and there are a few steps to consider before using it in the production environment. In this article, we describe various technics that can help you to plan and adequately use of Apache Ignite as cutting-edge caching technology.

  • Do proper capacity planning before using Ignite cluster. Do paperwork for understanding the size of the cache, number of CPUs or how many JVMs will be required. Let’s assume that you are using Hibernate as an ORM in 10 application servers and wish to use Ignite as an L2 cache. Calculate the total memory usages and the number of Ignite nodes you have to need for maintaining your SLA. An incorrect number of the Ignite nodes can become a bottleneck for your entire application. Please use the Apache Ignite official documentation for preparing a system capacity planning.
  • Select the best deployment option. You can use Ignite as an embedded or a real cluster topology. All of them contains a few pros and cons. When Ignite is running in the same JVM (in embedded mode) with the application, the network roundtrip for getting data from the cache is minimum. However, in this case, Ignite uses the same JVM resources along with the application which can impact on the application performance. Moreover, in the embedded mode, if the application dies, the Ignite node also fails. On the other hand, when Ignite node is running on a separate JVM, there is a minimal network overhead for fetching the data from the cluster. So, if you have a web application with a small memory footprint, you can consider using Ignite node in the same JVM.
  • Use on-heap caching for getting maximum performance. By default, Ignite uses Java off-heap for storing cache entries. When using off-heap to store data, there is always some overhead of de/serialization of data. To mitigate the latency and get the maximum performance you can use on-heap caching. You should also take into account that, Java heap size is almost limited and there is a GC (Garbage collection) overhead whenever using on-heap caching. Therefore, consider using on-heap caching whenever you are using a small limited size of a cache, and the cache entries are almost constants.
  • Use Atomic cache mode whenever possible. If you do not need strong data consistency, consider using the atomic mode. In an atomic mode, each DML operation will either succeed or fail and, neither Read nor Write operation will lock the data. This mode gives a better performance than the transactional mode. An example of using an atomic cache configuration is shown below.

    <property name="cacheConfiguration">
        <list>
            <bean class="org.apache.ignite.configuration.CacheConfiguration">
                <property name="name" value="testCache" />
                <property name="atomicityMode" value="ATOMIC" />
            </bean>
        </list>
    </property>
    

  • Disable unnecessary internal event's notification. Ignite has a rich event system to notify users/nodes about various events, including cache modification, eviction, compaction, topology changes, and a lot more. Since thousands of events per second are generated, it creates an additional load on the system. This can lead to significant performance degradation. Therefore, it is highly recommended to enable only those events that your application logic requires.

    <bean class="org.apache.ignite.configuration.IgniteConfiguration">
        <!-- Enable events that you need and leave others disabled -->
        <property name="includeEventTypes">
            <list>
                <util:constant static-field="org.apache.ignite.events.EventType.EVT_TASK_STARTED"/>
                <util:constant static-field="org.apache.ignite.events.EventType.EVT_TASK_FINISHED"/>
                <util:constant static-field="org.apache.ignite.events.EventType.EVT_TASK_FAILED"/>
            </list>
        </property>
    </bean>
    

  • Turn off backups copy. If you are using PARTITIONED cache and the data loss is not critical for you, consider disabling backups for the PARTITIONED cache. When backups are enabled, Ignite cache engine maintains a remote copy of each entry, which requires network exchanges. To turn off the backups copy, use the following cache configuration:

    <bean class="org.apache.ignite.configuration.IgniteConfiguration">
        <property name="cacheConfiguration">
            <bean class="org.apache.ignite.configuration.CacheConfiguration">
                <!-- Set cache mode. -->
                <property name="cacheMode" value="PARTITIONED"/>
                <!-- Set number of backups to 0-->
                <property name="backups" value="0"/>
            </bean>
        </property>
    </bean>
    
  • Synchronizing the requests for the same key. Let's explain by an example. Assume, your application has to handle 5000 requests per second. Most of them requested by one key. All the threads follow the following logic: If there is no value for the key in the cache, I query to the database. At the ends, each of the thread goes to the database and updates the value for the key into the cache. As a result, the application spends more times than if the cache was not at all. This is one of the common reasons when your application slows down whenever you are using a cache.

    However, the solution to this problem is simple: synchronizing the requests for the same keys. From version 2.1, Apache Ignite support @Cacheable annotation with sync attributes which ensure that a single thread is forming the cache value. To achieve this, you have to add the sync attribute as follows:

    @Cacheable(value = "exchangerate", sync = true)
    public String getExchangerate(String region) {
    }
    
  • Turn off or tune durable memory. Since version 2.1, Apache Ignite has its own persistence implementation. Unfortunately, persistence slows down the system. The WAL slows down the system even more. If you do not need the data durability, you can disable or turn off the WAL archiving. In Apache Ignite, starting from version 2.4, it is possible to disable WAL without restarting the entire cluster as shown below:

    ALTER TABLE tableName NOLOGGING
    ALTER TABLE tableName LOGGING
    

    By the way, you can also tune the WAL logging level according to your requirements. By default, the WAL log level is enabled on DEFAULT mode, which guaranty the highest level of data durability. You can change the log to one of the following levels:

    1. LOG_ONLY.
    2. BACKGROUND.
    3. NONE.

Caching gives enormous performance benefits, saves unnecessary network roundtrips and reduce CPU costs. Many believe that caching is such an easy way to make everything faster and cooler. However, as practice shows, most often incorrect use of caching makes thing worse. Caching is the mechanism that only gives performance boosts when you use it correctly. So, remember this before implementing it in your project, take measurements before and after on all related cases.

Don't hesitate to leave your comments or ideas if you have any. Portions of this article were taken from The Apache Ignite Book. If it got you interested, check out the rest of the book for more helpful information.

Friday

A Simple Checklist for Apache Ignite Beginners

If you're just starting with this great open source framework, don't worry, we're here to help. Check out this great resource to help get you going.


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:


TCP/UDP Port Number Description
TCP 10800 Default port for thin client connection
TCP 11211 Default JDBC port
TCP 47100 Default local communication port
UDP 47400
TCP 47500 Default local discovery port
TCP 8080 Default port for REST API
TCP 49128 Default port for JMX connection
TCP 31100~31200 Default time server port
TCP 48100~48200 Default shared memory port


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:


N Check it out
1 Use proper configuration files to connect through Ignite Visor.
2 Open ports that you need to work with the Ignite node.
3 Configure and read logs.
4 Avoid IPv6.
5 Use TcpDiscoveryVmIpFinder on the home office network.
6 Keep track of the baseline topology.

Monday

Book review: The Apache Ignite book by Md Sadruddin

The book review was done by Md Sadruddin and publish on his web site itteratory.com. The part of the review is published here with permission by Md Sadruddin.

Last year, as I was working with Apache Ignite, I was desperately in search of a book that I could rely upon in terms of clearing my doubts. A book that would help me learn the product in a holistic manner. And as my search was on, I bumped into the book by Shamim Ahmed Bhuiyan, Michael Zheludkov, and Timur Isachenko. I was super impressed with it as I scanned through the book. I also put up a review of that version of the book here.


The product Apache Ignite has been evolving in a rapid speed. It introduced many new features, different architectural revamp etc as the new versions were released. But as the new features got added with the newly released versions, there came a need of the new version of the book covering these new features. I found out Shamim Ahmed Bhuiyan and Michael Zheludkov are already on their mission to release a new edition of the book. I was eagerly waiting for the same to be released. I scanned through the book as soon as I got hold of it. Here, in this blog, I’ll share my personal experience as I browsed through the book.


With the newer versions, the products evolved and gave tons of new features to explore and work on.
As I have already gone through the first version of the book, I thought of turning to new one again to update myself and gather an all-around knowledge about the new features, new architecture etc instead of relying only on the Ignite official documentation (which is a great knowledge center as well. No doubt!). This new book is excellent and it pleasantly caters to both developers and solution/technical architects community with utmost ease.
In this new version of the book, there are 10 chapters. In the very first chapter of "Introduction", the authors introduced the product, its evolution since its inception and comparison with other different products.


In the second chapter "Getting started with Apache Ignite", we get to know how to starta single node/multi-nodes Ignite instances. We get to learn how we can use docker to run Ignite instances. It also takes us through setting up SQL IDE where you can run SQL queries against cache. It also touches upon Apache Ignite SQLLINE cli. This chapter introduces us with the H2 database which is Ignite’s SQL engine. It also teaches us on how to use H2 web console. We can use this web console to administrate H2 database, run SQL queries etc. It also takes us through sample JAVA program to read/write from/to Ignite cache. It touches upon Apache Ignite thin client, REST API for manipulating cache.

In the third chapter called "Apache Ignite Use cases", the book introduces different possible use cases where Ignite can be used, various design decisions. This is a very helpful guide to the solution designers. 
After covering these basics, the authors then jump to the fourth chapter called "Architectural deep dive". It’s a long and massive chapter covering cluster topology, partitioning, replication strategy, different caching strategy etc. It covers Ignite’s positioning in the CAP triangle. It also covers durable memory architecture, paging, persistence feature and many other very useful features of the Ignite product. All in all, this chapter covers your need as an architect or solution designer. 
In the next chapter (fifth) called "Intelligent caching", the book details Ignite’s caching capabilities, use of this product for accelerating application performance. It covers many interesting topics like web session clustering, recommendation on preparing caching layer, best practices. It also presents many interesting examples. 
In the sixth chapter called "Database", the book details on the Ignite’s database features. This is also a long chapter covering Ignite native persistence, tables, indexes, joins and a plethora of other related concepts. As a solution designer, this is definitely one chapter that you will spend time on, in case you plan to use Ignite’s persistence feature i.e using Ignite as a database. 
In chapter seven, the book covers "Distributed computing" and touches upon how Ignite can be useful in modern day architectures like micro-services. It covers map-reduce, fork-join, collocation of computation and data. Another very useful chapter. 
In the eighth chapter, the book covers another big elephant topic "Streaming and complex event processing". Here authors details Ignite’s streaming and CEP capability and use cases where it can be used. 
In the next chapter nine, the book focuses on Ignite’s use in "Accelerating Big data computing" with good examples. 
In the final chapter ten, the book covers an essential topic on "Management and monitoring". It talks about Ignite’s built-in capabilities and also 3rd party tools that can be used to manage and monitor the Ignite cluster.
As in the previous version, one striking aspect of the book is its easy language. I also loved the way the authors explained various terminologies and jargon that are used in this book. As I read through the book, I had several design related questions and got the answers from the book itself. The book is self contained and I didn’t have to browse through the internet to understand different topics/concepts introduced by the authors. Real life examples and code fragments help explain different concepts and topics very easily. The code is also available in github for reference. You code as you read and that’s very cool!! The balance of theory, coding, examples make reading the book very fun filled and enlightening. You don’t get bored!
To conclude, this book has been very handy to me and the reading experience is fantastic. I definitely recommend this book to Ignite users; doesn’t matter if you are a developer, support team member, architect or solution designed. Everyone has got something or other to learn from this book and that too in an easy manner. All I can say is happy reading!! and comment below in case you have some questions on the book or just to share how your experience have been.
The book is currently available in the leanpub. You can check it out here.

Tuesday

Using Apache Ignite thin client - Apache Ignite insider blog

From the version 2.4.0, Apache Ignite introduced a new way to connect to the Ignite cluster, which allows communication with the Ignite cluster without starting an Ignite client node. Historically, Apache Ignite provides two notions of client and server nodes. Ignite client node intended as lightweight mode, which does not store data (however, it can store near cache), and does not execute any compute tasks. Mainly, client node used to communicate with the server remotely and allows manipulating the Ignite Caches using the whole set of Ignite API’s. There are two main downsides with the Ignite Client node:

  • Whenever Ignite client node connects to the Ignite cluster, it becomes the part of the cluster topology. The bigger the topology is, the harder it is for maintaining.
  • In the client mode, Apache Ignite node consumes a lot of resources for performing cache operations.

To solve the above problems, Apache Ignite provides a new binary client protocol for implementing thin Ignite client in any programming language or platforms.

Note that, word thin means, it doesn’t start any Ignite node for communicating with the Ignite cluster and doesn’t implement any discovery/communication SPI logic.

Thin client connects to the Ignite cluster through a TCP socket and performs CRUD operations using a well-defined binary protocol. The protocol is a fully socket-based, request- response style protocol. The protocol is designed to be strict enough to ensure standardization in the communication (such as connection handshake, message length, etc.), but still flexible enough that developers may expand upon the protocol to implement custom features.

Apache Ignite provides brief data formats and communication details in the documentation for using the binary protocol.Ignite already supports .NET, and Java thin client builds on top of the protocol and plans to release a thin client for major languages such as goLang, python, etc. However, you can implement your thin client in any favorite programming language of your choice by using the binary protocol.

Also note that, the performance of the Apache Ignite thin client is slightly lower than Ignite client node as it works through an intermediary node. Assume that, you have two nodes of the Apache Ignite A, B and you are using a thin client C for retrieving data from the cluster. With the thin client C, you have connected to the node B, and whenever you try to retrieve any data that belongs to the node A, the requests always go through the client B. In case of the Ignite client node, it sends the request directly to the node A.

Most of the times, you should not care about how the message formats look like, or the socket handshake performs. Thin client for every programming language encapsulates the ugly hard work under the hood for you. Anyway, if you want to have a deep dive into the Ignite binary protocol or have any issue to create your own thin client, please refer to the Ignite documentation.

Before moving on to more advanced topics, let’s have a look at a simple application to use Ignite thin client. In this simple application, I show you the bits and pieces you need to get started with the thin client. The source code for the examples is available at the GitHub repository, see chapter-2.

Step 1. Clone or download the project from the GitHub repository. If you are planning to develop the project from scratch, add the following maven dependency in your pom.xml file. The only ignite-core library need for the thin client, the rest of the libraries only used for logging.

<dependency>
    <groupId>org.apache.ignite</groupId>
    <artifactId>ignite-core</artifactId>
    <version>2.6.0</version>
</dependency>
<!-- Logging wih SLF4J -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>1.6.1</version>
</dependency>
<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>1.0.1</version>
</dependency>
<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-core</artifactId>
    <version>1.0.1</version>
</dependency>

Step 2. Now, let's create a new Java class with the name HelloThinClient.
Step 3. Copy and paste the following source code. Do not forget to save the file.

import org.apache.ignite.IgniteException;
import org.apache.ignite.Ignition;
import org.apache.ignite.client.ClientCache;
import org.apache.ignite.client.IgniteClient;
import org.apache.ignite.configuration.ClientConfiguration;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class HelloThinClient {
 private static final Logger logger = LoggerFactory.getLogger(HelloThinClient.class);
 private static final String HOST = "127.0.0.1";
 private static final String PORT = "10800";
 private static final String CACHE_NAME = "thin-cache";

 public static void main(String[] args) {
  logger.info("Simple Ignite thin client example working over TCP socket.");
  ClientConfiguration cfg = new ClientConfiguration().setAddresses(HOST + ":" + PORT);
  try (IgniteClient igniteClient = Ignition.startClient(cfg)) {
   ClientCache < String, String > clientCache = igniteClient.getOrCreateCache(CACHE\ _NAME);
   // put a few value
   clientCache.put("Moscow", "095");
   clientCache.put("Vladimir", "033");
   // get the region code of the Vladimir String val = clientCache.get("Vladimir");
   logger.info("Print value: {}", val);
  } catch (IgniteException e) {
   logger.error("Ignite exception:", e.getMessage());
  } catch (Exception e) {
   logger.error("Ignite exception:", e.getMessage());
  }
 }
}

Step 4. Let's have a closer look at the program we have written above.

private static final Logger logger = LoggerFactory.getLogger(HelloThinClient.class);
 private static final String HOST = "127.0.0.1";
 private static final String PORT = "10800";
 private static final String CACHE_NAME = "thin-cache";

First, we have declared a few constants: logger, host IP address, port and the cache name that we are going to create. If you have a different IP address, you should change it here. Port 10800 is the default for Ignite thin client.

СlientConfiguration cfg = new ClientConfiguration().setAddresses(HOST+":"+PORT);

These are our next exciting line in the program. We have created an instance of the Ignite СlientConfiguration and passed the address we declared above. In the next try-catch block, we have defined a new cache with name thin-cache and put 2 key-value pairs. We also used Ignition.startClient method to initialize a connection to Ignite node.

try (IgniteClient igniteClient = Ignition.startClient(cfg)) {
   ClientCache < String, String > clientCache = igniteClient.getOrCreateCache(CACHE\ _NAME);
   // put a few value
   clientCache.put("Moscow", "095");
   clientCache.put("Vladimir", "033");
   // get the region code of the Vladimir String val = clientCache.get("Vladimir");
   logger.info("Print value: {}", val);
  } catch (IgniteException e) {
   logger.error("Ignite exception:", e.getMessage());
  } catch (Exception e) {
   logger.error("Ignite exception:", e.getMessage());
  }
}

Later, we retrieved the value of key Vladimir and printed the value in the console.

Step 5. Start your Apache Ignite single node cluster if it is not started yet. Use the following command in your favorite terminal.

$ IGNITE_HOME/bin/ignite.sh

Step 6. To build the project, issue the following command.

$ mvn clean install

This will run Maven, telling it to execute the install goal. This goal will compile, test, and package your project code and then copy it into the local dependency repository. The first time the build process will take a few minutes to complete, after successful compilation, an executable jar named HelloThinClient-runnable.jar will be created in the target directory.

Step 7. Run the application by typing the following command.

$ java -jar .\target\HelloThinClient-runnable.jar

You should see a lot of logs into the terminal. At the end of the log, you should find something like this.

Figure 1.

The application connected through the TCP socket to the Ignite node and performed put and get operation on cache thin-cache. If you take a look at the Ignite node console, you should notice that Ignite cluster topology has not been changed.

Figure 2.