This Reference Manual covers all editions of Hazelcast IMDG. Throughout this manual:

The Pro and Enterprise editions offer all the features of the open source edition.

Hazelcast IMDG and Hazelcast Reference Manual are free and provided under the Apache License, Version 2.0. Hazelcast IMDG Pro and Enterprise are commercially licensed by Hazelcast, Inc.

For more detailed information on licensing, see the License Questions appendix.

Hazelcast is a registered trademark of Hazelcast, Inc. All other trademarks in this manual are held by their respective owners.

Support for Hazelcast is provided via GitHub, Mail Group and StackOverflow.

For information on the commercial support for Hazelcast IMDG and Hazelcast IMDG Enterprise, see hazelcast.com.

See the Release Notes document for the new features, enhancements and fixes performed for each Hazelcast IMDG release.

You can contribute to the Hazelcast IMDG code, report a bug, or request an enhancement. See the following resources:

Hazelcast partners with leading hardware and software technologies, system integrators, resellers and OEMs including Amazon Web Services, Vert.x, Azul Systems, C2B2. See the Partners page for the full list of and information on our partners.

You can use the Hazelcast Command Line Interface (CLI) to install and start Hazelcast IMDG.

Run the following commands to install Hazelcast CLI:

After the installation of Hazelcast CLI, the package managers will display the installation directory and usage information.

Currently, the CLI way is meant for development purposes, not for a production usage. For production or if you prefer other ways, take a look at Installing and Upgrading.

Use the following command on your terminal/command line to start a standalone Hazelcast member:

Now you have a 1-member cluster. To add one more member to the cluster, open another terminal/command line and rerun the above command. The members discover each other automatically and form a 2-member cluster. You should see happening it with log output in the command line like:

Note that these members are started with the default configuration. The location of the hazelcast.xml is printed on the first line of the output of the above command.

Having a running cluster as started in the above section, let’s create a client application that connects to this cluster, creates a map and populates it. Below, we first briefly give how to install a client of your preference and then an example code for each. We are assuming that the members and clients are on the same machine for simplicity.

For comprehensive information on the clients, see the following sections:

Hazelcast Management Center helps you to monitor and manage your IMDG cluster. After you created your cluster and client application as depicted in the above sections, let’s connect Management Center to the cluster. Note that having client applications is not a must to use the Management Center; you can connect it to your cluster that does not have any clients.

Use the following command to start the Management Center:

Then, open your preferred web browser to http://localhost:8080 and select the default security provider to provide a username and password. Log in to Management Center using those credentials and create a cluster connection; the defaults should work fine. If using Docker for members, find out the Docker IP address of cluster rather than the default of localhost.

For comprehensive information on Management Center, see its documentation.

In this chapter, you have learnt starting a Hazelcast IMDG cluster, inserting data to it via clients and monitoring it through Management Center. Now, you may want to perform the following:

You can always reach out via Slack, Mail Group or StackOverflow.

Hazelcast IMDG is an open-source distributed in-memory object store supporting a wide variety of data structures.

You can use Hazelcast IMDG to store your data in RAM, spread and replicate it across your cluster of machines, and perform computations on it. Replication gives you the resilience to failures of cluster members.

Hazelcast IMDG is highly scalable and available. Distributed applications can use it for distributed caching, synchronization, clustering, processing, pub/sub messaging, etc.

It is implemented in Java language and has clients for Java, C++, .NET, REST, Python, Go and Node.js. Hazelcast IMDG also speaks Memcached and REST protocols. It plugs into Hibernate and can easily be used with any existing database system.

Hazelcast IMDG makes distributed computing simple by offering distributed implementations of many developer-friendly interfaces. For example, the Map interface provides an In-Memory Key Value store which confers many of the advantages of NoSQL in terms of developer friendliness and developer productivity.

Your cloud-native applications can easily use Hazelcast IMDG. It is flexible enough to use as a data and computing platform out-of-the-box or as a framework for your own cloud-native applications and microservices.

Hazelcast IMDG is designed to be lightweight and easy to use. Since it is delivered as a compact library (JAR) and has no external dependencies other than Java, it easily plugs into your software solution and provides distributed data structures and computing utilities.

It is designed to scale up to hundreds of members and thousands of clients. When you add new members, they automatically discover the cluster and linearly increase both the memory and processing capacity. The members maintain a TCP connection between each other and all communication is performed through this layer. Each cluster member is configured to be the same in terms of functionality. The oldest member (the first member created in the cluster) automatically performs the data assignment to cluster members. If the oldest member dies, the second oldest member takes over.

Hazelcast IMDG offers simple scalability, partitioning (sharding), and re-balancing out-of-the-box. It does not require any extra coordination processes. NoSQL and traditional databases are difficult to scale out and manage. They require additional processes for coordination and high availability. With Hazelcast IMDG, when you start another process to add more capacity, data and backups are automatically and evenly balanced.

Hazelcast’s Distinctive Strengths

Finally, Hazelcast has a vibrant open source community enabling it to be continuously developed.

Hazelcast is a fit when you need:

You can see the features for all Hazelcast IMDG editions in the following architecture diagram.

For more information on Hazelcast IMDG’s Architecture, see the white paper An Architect’s View of Hazelcast.

You can deploy a Hazelcast cluster in two ways: Embedded or Client/Server.

If you have an application whose main focal point is asynchronous or high performance computing and lots of task executions, then Embedded deployment is the preferred way. In Embedded deployment, members include both the application and Hazelcast data and services. The advantage of the Embedded deployment is having a low-latency data access.

See the below illustration.

In the Client/Server deployment, Hazelcast data and services are centralized in one or more server members and they are accessed by the application through clients. You can have a cluster of server members that can be independently created and scaled. Your clients communicate with these members to reach to Hazelcast data and services on them.

See the below illustration.

Hazelcast provides native clients (Java, .NET and C++), Memcache and REST clients, Python and Node.js client implementations.

Client/Server deployment has advantages including more predictable and reliable Hazelcast performance, easier identification of problem causes and, most importantly, better scalability. When you need to scale in this deployment type, just add more Hazelcast server members. You can address client and server scalability concerns separately.

Note that Hazelcast member libraries are available only in Java. Therefore, embedding a member to a business service, it is only possible with Java. Applications written in other languages (.NET, C++, Node.js, etc.) can use Hazelcast client libraries to access the cluster. See the Hazelcast Clients chapter for information on the clients and other language implementations.

If you want low-latency data access, as in the Embedded deployment, and you also want the scalability advantages of the Client/Server deployment, you can consider defining Near Caches for your clients. This enables the frequently used data to be kept in the client’s local memory. See the Configuring Client Near Cache section.

The memory segments in Hazelcast IMDG are called partitions. They can contain hundreds or thousands of data entries each, depending on the memory capacity of your system.

The partitions are distributed equally among the members of the cluster. Hazelcast also creates backups of these partitions which are also distributed in the cluster.

By default, Hazelcast creates a single copy/replica of each partition. You can configure Hazelcast so that each partition can have multiple replicas. One of these replicas is called "primary" and others are called "backups". The cluster member which owns the "primary" replica of a partition is called the "partition owner". When you read or write a particular data entry, you transparently talk to the partition owner that contains the data entry.

By default, Hazelcast offers 271 partitions. When you start a cluster with a single member, it owns all of 271 partitions (i.e., it keeps primary replicas for 271 partitions). The following illustration shows the partitions in a Hazelcast cluster with single member.

When you start a second member on that cluster (creating a Hazelcast cluster with two members), the partition replicas are distributed as shown in the illustration here.

In the illustration, the partition replicas with black text are primaries and the partition replicas with blue text are backups. The first member has primary replicas of 135 partitions (black) and each of these partitions are backed up in the second member (i.e., the second member owns the backup replicas) (blue). At the same time, the first member also has the backup replicas of the second member’s primary partition replicas.

As you add more members, Hazelcast moves some of the primary and backup partition replicas to the new members one by one, making all members equal and redundant. Thanks to the consistent hashing algorithm, only the minimum amount of partitions are moved to scale out Hazelcast. The following is an illustration of the partition replica distributions in a Hazelcast cluster with four members.

Hazelcast distributes partitions' primary and backup replicas equally among the members of the cluster. Backup replicas of the partitions are maintained for redundancy.

Hazelcast also offers lite members. These members do not own any partition. Lite members are intended for use in computationally-heavy task executions and listener registrations. Although they do not own any partitions, they can access partitions that are owned by other members in the cluster.

Hazelcast can be used:

To install Hazelcast via command line interface, run the following commands:

For more information visit the GitHub repository of the Command Line Interface (CLI).

You can find Hazelcast in standard Maven repositories. If your project uses Maven, you do not need to add additional repositories to your pom.xml or add hazelcast-4.1.jar file into your classpath (Maven does that for you). Just add the following lines to your pom.xml:

Above dependency (hazelcast-all) includes both member and Java client libraries of Hazelcast IMDG. A separate Java client module and dependency do not exist. See here for the details.

Hazelcast is distributed in a form of Docker images.

You can run the following command to launch the Hazelcast Docker container:

This command will pull Hazelcast Docker image and run a new Hazelcast instance.

See the following for more details:

You can download and install Hazelcast IMDG yourself. You only need to:

When you download and extract the Hazelcast ZIP or TAR.GZ package, you will see the start/stop.sh (for Linux) and start/stop.bat (for Windows) scripts under the /bin folder. These scripts start/stop a Hazelcast member. See the Quick Start chapter to see the start scripts in action.

There are also some other scripts in the download archive whose usage descriptions are given in their related sections including the Using the Script cluster.sh, CP Subsystem Management APIs section and Using the healthcheck.sh Script sections. You can also check the full list of scripts in the readme.html of your download archive.

A simple option for deploying Hazelcast is Hazelcast Cloud. It delivers enterprise-grade Hazelcast software in the cloud. You can deploy, scale and update your Hazelcast easily using Hazelcast Cloud; it maintains the clusters for you. You can use Hazelcast Cloud as a low-latency high-performance caching or data layer for your microservices, and it is also a nice solution for state management of serverless functions (AWS Lambda).

Hazelcast Cloud uses Docker and Kubernetes, and is powered by Hazelcast IMDG Enterprise HD. It is initially available on Amazon Web Services (AWS), to be followed by Microsoft Azure and Google Cloud Platform (GCP). Since it is based on Hazelcast IMDG Enterprise HD, it features advanced functionality such as TLS, multi-region, persistence, and high availability.

Hazelcast provides a few methods to simplify deploying Hazelcast cluster into Kubernetes-based environments.

You can deploy your Hazelcast Enterprise cluster in VMware Tanzu (former Pivotal Cloud Foundry). See the following for details:

Hazelcast can be deployed into different cloud providers. Thanks to dedicated Hazelcast Cloud Discovery plugins there is no static IP configuration needed and Hazelcast cluster is resilient to availability zone failures.

Hazelcast IMDG offers two commercially licensed editions: Pro and Enterprise. The supported features differ in your Hazelcast setup according to the license type you own.

See also here for a more detailed feature comparison between the editions.

Hazelcast IMDG Enterprise Feature

This chapter explains the procedure of upgrading the version of Hazelcast members in a running cluster without interrupting the operation of the cluster.

Java project Jigsaw brought a new Module System into Java 9 and newer. Hazelcast supports running in the modular environment. If you want to run your application with Hazelcast libraries on the modulepath, use the following module name:

Don’t use hazelcast-all-4.1.jar or hazelcast-enterprise-all-4.1.jar on the modulepath as it could lead to problems in module dependencies for your application. You can still use them on the classpath.

The Java Module System comes with stricter visibility rules. It affects Hazelcast which uses internal Java API to reach the best performance results.

Hazelcast needs the java.se module and access to the following Java packages for a proper work:

You can provide the access to the above mentioned packages by using --add-exports and --add-opens (for the reflective access) Java arguments.

Example: Running a member on the classpath

Example: Running a member on the modulepath

This example expects hazelcast-4.1.jar placed in the lib directory.

Following table summarizes the version compatibility between Hazelcast IMDG and various vendors' Java Virtual Machines (JVMs).

In this short tutorial, you perform the following activities:

Let’s begin.

This is the configuration option where you use an XML or a YAML configuration file. When you download and unzip hazelcast-4.1 .zip, you see the following files present in the /bin folder, which are standard configuration files:

A part of the default XML/YAML configurations is shown as an example below.

Besides declarative configuration, you can configure your cluster programmatically. For this you can create a Config object, set/change its properties and attributes and use this Config object to create a new Hazelcast member. Following is an example code which configures some network and Hazelcast Map properties.

To create a Hazelcast member with the above example configuration, pass the configuration object as shown below:

You can also create a named Hazelcast member. In this case, you should set instanceName of Config object as shown below:

To retrieve an existing Hazelcast member by its name, use the following:

To retrieve all existing Hazelcast members, use the following:

If you want to specify your own configuration file to create Config, Hazelcast supports several ways including filesystem, classpath, InputStream and URL.

Building Config from the XML declarative configuration:

Building Config from the YAML declarative configuration:

You can use system properties to configure some aspects of Hazelcast. You set these properties as name and value pairs through declarative configuration, programmatic configuration or JVM system property. Following are examples for each option.

Declarative Configuration:

Programmatic Configuration:

Using JVM’s System class or -D argument:

System.setProperty( "hazelcast.property.foo", "value" );

or

java -Dhazelcast.property.foo=value

You will see Hazelcast system properties mentioned throughout this Reference Manual as required in some of the chapters and sections. All Hazelcast system properties are listed in the System Properties appendix with their descriptions, default values and property types as a reference for you.

If you use Hazelcast with Spring you can declare beans using the namespace hazelcast. When you add the namespace declaration to the element beans in the Spring context file, you can start to use the namespace shortcut hz to be used as a bean declaration. Following is an example Hazelcast configuration when integrated with Spring:

See the Integration with Spring section for more information on Hazelcast-Spring integration.

You can override your clusters' configurations without having to modify the XML or YAML configuration files. Hazelcast makes this possible using the system properties or environment variables.

For example, if you just want to override cluster-name, you would need to craft a declarative configuration as follows:

Instead of the above, you can achieve the same purpose using the following on the command line:

Recognized and unrecognized configuration entries will be logged when Hazelcast starts.

When overriding the configuration provided in a custom file, remember to overwrite the whole configuration sections at once; if you don’t, the remaining entries will be set to their default values.

As described above, Hazelcast can be configured in a declarative or programmatic way; configuration must be completed before starting a Hazelcast member and this configuration cannot be altered at runtime, thus we refer to this as static configuration.

It is possible to dynamically add configuration for certain data structures at runtime; these can be added by invoking one of the Config.add*Config methods on the Config object obtained from a running member’s HazelcastInstance.getConfig() method. For example:

Dynamic configuration elements must be fully configured before the invocation of add*Config method: at that point, the configuration object is delivered to every member of the cluster and added to each member’s dynamic configuration, so mutating the configuration object after the add*Config invocation does not have an effect.

As dynamically added data structure configuration is propagated across all cluster members, failures may occur due to conditions such as timeout and network partition. The configuration propagation mechanism internally retries adding the configuration whenever a membership change is detected. However if an exception is thrown from add*Config method, the configuration may have been partially propagated to some cluster members and adding the configuration should be retried by the user.

Adding a new dynamic configuration is supported for all add*Config methods except the following:

Keep in mind that this feature also works for Hazelcast Java clients. See the following example:

When you start a Hazelcast member without passing a Config object, as explained in the Configuring Programmatically section, Hazelcast checks the member’s configuration as follows:

Before configuring Hazelcast, please try to work with the default configuration to see if it works for you. This default configuration should be fine for most of the users. If not, you can consider to modify the configuration to be more suitable for your environment.

You can give a custom strategy to match an item name to a configuration pattern. By default Hazelcast uses a simplified wildcard matching. See Using Wildcards section for this. A custom configuration pattern matcher can be given by using either member or client config objects, as shown below:

And the following is an example pattern matcher:

Hazelcast supports wildcard configuration for all distributed data structures that can be configured using Config, that is, for all except IAtomicLong, IAtomicReference. Using an asterisk (*) character in the name, different instances of maps, queues, topics, semaphores, etc. can be configured by a single configuration.

A single asterisk (*) can be placed anywhere inside the configuration name.

For instance, a map named com.hazelcast.test.mymap can be configured using one of the following configurations:

A queue named com.hazelcast.test.myqueue can be configured using one of the following configurations:

In your Hazelcast and/or Hazelcast Client declarative configuration, you can use variables to set the values of the elements. This is valid when you set a system property programmatically or you use the command line interface. You can use a variable in the declarative configuration to access the values of the system properties you set.

For example, see the following command that sets two system properties.

Let’s get the values of these system properties in the declarative configuration (XML/YAML) of Hazelcast, as shown below.

This also applies to the declarative configuration of Hazelcast Java Client, as shown below.

If you do not want to rely on the system properties, you can use the XmlConfigBuilder or YamlConfigBuilder and explicitly set a Properties instance, as shown below.

Variable replacers are used to replace custom strings during loading the configuration, e.g., they can be used to mask sensitive information such as usernames and passwords. Of course their usage is not limited to security related information.

Variable replacers implement the interface com.hazelcast.config.replacer.spi.ConfigReplacer and they are configured only declaratively: in the Hazelcast’s declarative configuration files, i.e., hazelcast.xml, hazelcast.yaml and hazelcast-client .xml, hazelcast-client.yaml. See the ConfigReplacers Javadoc for basic information on how a replacer works.

Variable replacers are configured within the element <config-replacers> under <hazelcast>, as shown below.

As you can see, <config-replacers> is the parent element for your replacers, which are declared using the <replacer> sub-elements. You can define multiple replacers under the <config-replacers>. Here are the descriptions of elements and attributes used for the replacer configuration:

The following replacer classes are provided by Hazelcast as example implementations of the ConfigReplacer interface. Note that you can also implement your own replacers.

Each example replacer is explained in the below sections.

A Hazelcast cluster is a network of cluster members that run Hazelcast. Cluster members automatically join together to form a cluster. This automatic joining takes place with various discovery mechanisms that the cluster members use to find each other.

Please note that, after a cluster is formed, communication between cluster members is always via TCP/IP, regardless of the discovery mechanism used.

Hazelcast uses the following discovery mechanisms.

Auto Detection is a good way to start playing with Hazelcast. It tries to automatically detect the appropriate discovery plugin and apply it to your Hazelcast configuration. Assuming you have hazelcast-all on your classpath and your runtime is Kubernetes, Hazelcast automatically applies the Kubernetes discovery mechanism.

Below is a table with minimal requirements for each environment.

If multicast is not the preferred way of discovery for your environment, then you can configure Hazelcast to be a full TCP/IP cluster. When you configure Hazelcast to discover members by TCP/IP, you must list all or a subset of the members' host names and/or IP addresses as cluster members. You do not have to list all of these cluster members, but at least one of the listed members has to be active in the cluster when a new member joins.

To configure your Hazelcast to be a full TCP/IP cluster, set the following configuration elements. See the tcp-ip element section for the full descriptions of the TCP/IP discovery configuration elements.

The following is an example declarative configuration.

As shown above, you can provide IP addresses or host names for member elements. You can also give a range of IP addresses, such as 192.168.1.0-7.

Instead of providing members line-by-line as shown above, you also have the option to use the members element and write comma-separated IP addresses, as shown below.

<members>192.168.1.0-7,192.168.1.21</members>

If you do not provide ports for the members, Hazelcast automatically tries the ports 5701, 5702 and so on.

By default, Hazelcast binds to all local network interfaces to accept incoming traffic. You can change this behavior using the system property hazelcast.socket.bind.any. If you set this property to false, Hazelcast uses the interfaces specified in the interfaces element (see the Interfaces Configuration section). If no interfaces are provided, then it tries to resolve one interface to bind from the member elements.

With the multicast auto-discovery mechanism, Hazelcast allows cluster members to find each other using multicast communication. The cluster members do not need to know the concrete addresses of the other members, as they just multicast to all the other members for listening. Whether multicast is possible or allowed depends on your environment.

To set your Hazelcast to multicast auto-discovery, set the following configuration elements. See the multicast element section for the full description of the multicast discovery configuration elements.

The following is an example declarative configuration.

Pay attention to the multicast-timeout-seconds element. multicast-timeout-seconds specifies the time in seconds that a member should wait for a valid multicast response from another member running in the network before declaring itself the leader member (the first member joined to the cluster) and creating its own cluster. This only applies to the startup of members where no leader has been assigned yet. If you specify a high value to multicast-timeout-seconds, such as 60 seconds, it means that until a leader is selected, each member waits 60 seconds before moving on. Be careful when providing a high value. Also, be careful not to set the value too low, or the members might give up too early and create their own cluster.

Hazelcast members and native Java clients can find each other with multicast discovery plugin. This plugin is implemented using Hazelcast Discovery SPI. You should configure the plugin both at Hazelcast members and Java clients in order to use multicast discovery.

To configure your cluster to have the multicast discovery plugin, follow these steps:

The following is an example declarative configuration.

The following are the multicast discovery plugin configuration properties with their descriptions:

You can create clusters using the cluster-name configuration element.

You can separate and group your clusters in a simple way by specifying cluster names. Example groupings can be by development, production, test, app, etc. The following is an example declarative configuration.

You can also define the cluster configuration programmatically. A JVM can host multiple Hazelcast instances. Each Hazelcast instance can only participate in one group. Each Hazelcast instance only joins to its own group and does not interact with other groups. The following code example creates three separate Hazelcast instances--h1 belongs to the production cluster, while h2 and h3 belong to the development cluster.

Hazelcast can dynamically load your custom classes or domain classes from other members. A lite member can be designated as a class repository, but any member can provide classes to other members. For this purpose Hazelcast offers a distributed dynamic class loader.

The following is a brief working mechanism of the User Code Deployment feature:

You can also deploy your code from the client side for the following situations:

When this feature is enabled on the client, the client will deploy the classes to the members when connecting. This way, when a client adds a new class, the members do not require a restart to include it in their classpath.

You can also use the client permission policy to specify which clients are permitted to use User Code Deployment. See the Permissions section.

NOTE:

Hazelcast offers a generic object interface (GenericRecord) that is returned to the user when the domain class is missing on the classpath. For example, if PortableFactory is not given in the serialization configuration for a portable object, the user domain class cannot be created, and Hazelcast returns GenericRecord instead. In the previous Hazelcast IMDG releases, we were throwing HazelcastSerializationException("Could not create Portable for class-id: " + classId) for the same situation.

GenericRecord is an immutable object. It allows you to read the field of objects via the related field names. GenericRecord is applicable only to Portable objects.

You can use this feature when the cluster does not have the domain classes of the clients in a client-server architecture. On remote calls like distributed executor service or entry processors, you may need to access the domain object. In case the class of the domain object is not available on the cluster, GenericRecord allows to access, read and write the objects back without the class of the domain object on the classpath. Here is a read example with entry processor:

An alternative approach introduced in the previous Hazelcast IMDG releases is the User Code Deployment feature to deploy the classes from the client to the cluster. However, it has a restriction: you can not upload a new version of your class to the cluster if you use the portable versioning support. Loading two different versions of the same class on the JVM is not a problem that we want to solve: using GenericRecord, you can easily write different versions of your classes from the clients and access them without using the User Code Deployment feature.

With the introduction of GenericRecord, User Code Deployment should be used only for functional objects like Runnable, Callable and EntryProcessor.

You can also create a GenericRecord in portable format with GenericRecord.Builder as follows:

Note that the class definitions are better to be created once and used when creating different instances of the same type GenericRecord.

We have also added two convenience methods in GenericRecord for you to avoid passing a class definition. For example, if you want to modify a value and put it back using an entry processor, you don’t need to create a class definition. Instead you can create a builder from GenericRecord which carries the same class definition as follows:

Another convenience method is cloneWithBuilder. This is useful if you want to update only a couple of fields from the original genericRecord. In that case, the new builder carries both classDefinition and values from the original genericRecord. Here is the same example where we just update the age:

Another use case of this feature is on the client side (could also be a member): GenericRecord allows to read from/write to a cluster without having the related classes on the classpath. A client could work with the cluster without introducing the PortableFactory at the start. In this case, the client works with GenericRecords instead of domain classes. An example code snippet on the client side with a map is shown below:

Hazelcast distributes key objects into partitions using the consistent hashing algorithm. Multiple replicas are created for each partition and those partition replicas are distributed among Hazelcast members. An entry is stored in the members that own replicas of the partition to which the entry’s key is assigned. The total partition count is 271 by default; you can change it with the configuration property hazelcast.partition.count. See the System Properties appendix.

Hazelcast member that owns the primary replica of a partition is called as the partition owner. Other replicas are called backups. Based on the configuration, a key object can be kept in multiple replicas of a partition. A member can hold at most one replica of a partition (ownership or backup).

By default, Hazelcast distributes partition replicas randomly and equally among the cluster members, assuming all members in the cluster are identical. But what if some members share the same JVM or physical machine or chassis and you want backups of these members to be assigned to members in another machine or chassis? What if processing or memory capacities of some members are different and you do not want an equal number of partitions to be assigned to all members?

To deal with such scenarios, you can group members in the same JVM (or physical machine) or members located in the same chassis. Or you can group members to create identical capacity. We call these groups partition groups. Partitions are assigned to those partition groups instead of individual members. Backup replicas of a partition which is owned by a partition group are located in other partition groups.

Hazelcast has a flexible logging configuration and does not depend on any logging framework except JDK logging. It has built-in adapters for a number of logging frameworks and it also supports custom loggers by providing logging interfaces.

To use the built-in adapters, set the hazelcast.logging.type property to one of the predefined types below:

You can set hazelcast.logging.type through declarative configuration, programmatic configuration or JVM system property.

Declarative Configuration:

Programmatic Configuration

System Property

If the provided logging mechanisms are not satisfactory, you can implement your own using the custom logging feature. To use it, implement the com.hazelcast.logging.LoggerFactory and com.hazelcast.logging.ILogger interfaces and set the system property hazelcast.logging.class as your custom LoggerFactory class name.

You can also listen to logging events generated by Hazelcast runtime by registering LogListeners to LoggingService.

Through the LoggingService, you can get the currently used ILogger implementation and log your own messages too.

Below are example configurations for Log4j2 and Log4j. Note that Hazelcast does not recommend any specific logging library, these examples are provided only to demonstrate how to configure the logging. You can use your custom logging as explained above.

All network related configurations are performed via the network element in the Hazelcast XML configuration file or the class NetworkConfig when using programmatic configuration. Following subsections describe the available configurations that you can perform under the network element.