In this article, we will have a brief introduction into the Hazelcast world, and we start with some configuration aspects.

Hazelcast Configurations

To start, Hazelcast needs a set of configurations, such as the port number of the first node, activate/deactivate multicast support, and so forth. Besides the set of default configurations that are stored in the hazelcast-default.xml file that comes with the Hazelcast JAR, we can provide a custom set of configurations via XML or programmatically.

Hazelcast XML Configurations

Hazelcast supports declarative and programmatic configurations. Further, we will examine each of these cases via the most common usage cases.

Working with hazelcast.xml

When Hazelcast starts, it first checks the value of the hazelcast.config system property. Basically, via this system property, you specify the path where Hazelcast should look for the hazlecast.xml file (the path can be a normal one or a classpath reference with the prefix CLASSPATH). The hazelcast.xml file contains the custom configurations for Hazelcast. By default, this file should be located in the current working directory or the classpath. A simple hazelcast.xml file can look like this:

Related Articles

Notice that the above approach will ignore a potential existing hazlecast.xml! The Config object represents all the configurations to start a HazelcastInstance, and because we pass an "unused" cfg, it will contain the default configurations for Hazelcast. Most probably, you will use the preceding approach when you want to programmatically alter the default configurations.

In some examples, you may also see the following approach:

HazelcastInstance instance = Hazelcast.newHazelcastInstance();

Notice that the above approach will start with default configurations ONLY if there is no hazlecast.xml found! You can see such an application in the code that is delivered with this article, under the name HazelcastXML. Please refer to the download link at the end of this article. This application uses the above hazelcast.xml. When you will run this application ONCE, notice that the first node is started on port 6005, instead of the default one, 5701:

Figure 1: The first node in the cluster started at custom port 6005

If you run this code once more, a second node starts and these two nodes will form a cluster; this is possible because Hazelcast allows more than one instance (node) to be created on the same JVM. Check out Figure 2:

Working with XmlConfigBuilder

Another approach to configuring Hazelcast consists of using the XmlConfigBuilder class. Via this class, we can load the configurations from an XML file that can be referenced via a URL, file path, or input stream. For example, we can point to a location on disk (file path) as shown below:

Working with Config

As was said earlier, the Config class can be used to provide a programmatic configuration approach. For example, we may want to programmatically provide the same configurations as we did above via hazelcast.xml. This can be accomplished as demonstrated below:

Config Notes

The Config instances can be shared between threads, but should not be modified after they are used to create HazelcastInstances. Hazelcast does not copy configurations to each node. So, if one wants to share a data structure, it needs to be defined in every node exactly the same.

Hazelcast Structures to Store Data

Hazelcast comes with several data structures to store data, such as IList, IMap, MultiMap, and ISet. In this section, we will talk about IMap.

The concurrent, distributed, observable, and queryable map is the Hazelcast IMap. Here it is a simple usage of it: We declare a IMap and pre-populate it with some random data. Moreover, we don't explicitly specify keys; we use the Hazecast key generator (IdGenerator), which is capable of generating random keys across nodes:

If the map products exists (for example, it was configured and initialized in XML), Hazelcast will use that ma. Otherwise, it will create it as an empty map (as above).

The data stored in this map will be available for all nodes in the cluster. For example, on a single node, you may see something like in Figure 3, left side, while on two nodes, you will see something like in Figure 3, right side:

Figure 3: Hazelcast distributed map

The complete example is named HazelcastIMap.

Hazelcast Messaging

When we talk about Hazelcast messaging, we are talking about the mighty IQueue and ITopic. The IQueue is a concurrent, blocking, distributed, observable queue, and a simple example looks like the following:

Figure 4 demonstrates an output with one publisher and three subscribers:

Figure 4: One publisher and three subscribers

The complete example is named HazelcastTopic.

What to Read Further

Well, if the preceding examples look impressive, you must know that this is just the beginning. Next, you should try to explore more about the amazing power of Hazelcast and read about Hazelcast locking, transactions, JCache support, interacting with a RDBMS, and so on.