GridGain Developers Hub

GridGain 8.8.8 Release Notes

New Features

Improvements and Fixed Issues

Added Support for C++ Java Compute

You can now use the new Compute::ExecuteJavaTask method to execute Java compute tasks from C++ code by their names. For example:

Ignite ignite = Ignition::Get();
compute::Compute compute = ignite.GetCompute();

std::string echoValue = "Task returns this value";

std::string res = compute.ExecuteJavaTask<std::string>("", echoValue);

assert(res == echoValue);

Added Support for Compute Tasks in C++ Thin Clients

Compute tasks can now be performed by using C++ thin clients. For example, here is how you can execute a newly added compute task on :

IgniteClient client = IgniteClient::Start();
compute::ComputeClient compute = ignite.GetCompute();

std::string echoValue = "Task returns this value";

std::string res = compute.ExecuteJavaTask<std::string>("", echoValue);

assert(res == echoValue);

Added Support for Cache Templates in Hibernate L2

When working with Hibernate L2, you may want to use the same cache configuration for multiple caches. Now you can use preconfigured Cache Templates to apply the same configuration to multiple caches.

For example, the following configuration uses a single transactional-cache bean for multiple entities:

<bean parent="transactional-cache">
    <property name="name" value="com.mycompany.*"/>

Implemented Page Replacement Algorithms

When the amount of data stored on disk is bigger than the off-heap memory amount allocated for the data region, another page should be removed from off-heap to the disk to preload an appropriate page to off-heap memory.

There are three available algorithms:

  • Random-LRU algorithm;

  • Segmented-LRU algorithm;

  • CLOCK algorithm.

By default, CLOCK algorithm is used.

Page replacement algorithm is configured by the PageReplacementMode property of DataRegionConfiguration.

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
<!-- Memory configuration. -->
<property name="dataStorageConfiguration">
<bean class="org.apache.ignite.configuration.DataStorageConfiguration">
<property name="dataRegionConfigurations">
Defining a persistent data region with Segmented LRU page replacement mode.
<bean class="org.apache.ignite.configuration.DataRegionConfiguration">
<!-- Data region name. -->
<property name="name" value="persistent_data_region"/>
<!-- Enable persistence. -->
<property name="persistenceEnabled" value="true"/>
<!-- 20 GB maximum size (RAM). -->
<property name="maxSize" value="#{20L * 1024 * 1024 * 1024}"/>
<!-- Enabling SEGMENTED_LRU page replacement for this region.  -->
<property name="pageReplacementMode" value="SEGMENTED_LRU"/>
<!-- The rest of the configuration. -->
// Node configuration.
IgniteConfiguration cfg = new IgniteConfiguration();

// Memory configuration.
DataStorageConfiguration storageCfg = new DataStorageConfiguration();

// Creating a new data region.
DataRegionConfiguration regionCfg = new DataRegionConfiguration();

// Region name.

// Enabling persistence.

// 20 GB max size (RAM).
regionCfg.setMaxSize(20L * 1024 * 1024 * 1024);

// Enabling SEGMENTED_LRU page replacement for this region.

// Setting the data region configuration.

// Applying the new configuration.
This API is not presently available for C#/.NET. You can use XML configuration.
This API is not presently available for C++. You can use XML configuration.

Known Issues

Index Page Usage Metric is Incorrect

Index pages allocation metric is currently not being tracked correctly. This issue that will be fixed in the upcoming release.

GridGain May Crash when Using OpenJDK 11

In some rare environments, GridGain servers may crash with a SocketTimeoutException exception when running on OpenJDK 11. Consider using OpenJDK 8 or a different JDK provider instead.

Here is an example of the exception that can occur:

Exception in thread "main" Accept timed out
        at java.base/ Method)
        at java.base/
        at java.base/
        at java.base/
        at Example.main(

You can track the status of this issue in openJDK issue tracker.

Improvements and Fixed Issues

Community Edition Changes

Issue ID Category Description


Cluster Storage Engine

Fixed an issue that could lead to data desynchronization if a node is restarted during rebalancing under the load.


Cluster Metrics & Monitoring

Fixed an error with unregistering JMX metric.


GridGain Integrations

User can provide template cache configuration with an asterisk in the name (e.g. "*") and this template will be used for the auto creation of the Hibernate L2 cache.


Platforms & Thin Clients

Added compute functionality to C++ thin client.


Platforms & Thin Clients

CPP: Added an ability to run Java tasks by name: Compute::ExecuteJavaTask.


Cluster Storage Engine

Returned IGNITE_THRESHOLD_WAL_ARCHIVE_SIZE_PERCENTAGE for backwards compatibility.


Cluster Security

Upgraded Hadoop from 2.7.7 to 2.8.5 version to fix vulnerability.


Cluster Security

Upgraded Tomcat from 9.0.21 to 9.0.52 version to fix vulnerability.


Cluster Security

Upgraded slf4j from 1.7.7. to 1.7.32 version to fix vulnerability.


Cluster Data Replication

Fixed a race when changing update log, leading to the B+Tree corrupt in incremental DR.


Cluster Storage Engine

Fixed a rare issue on joins with empty LFS.


Cluster Communication

Exception while processing messages by the NIO server no longer affects other messages.


Cluster Storage Engine

Added automatic release of WAL segments when reaching the DataStorageConfiguration#maxWalArchiveSize.


Cluster Storage Engine

Added new page replacement algorithms: Replaced default implementation with the Clock algorithm.


Cluster SQL Engine

Log messages about long running and huge results queries are now throttled.


Cluster Storage Engine

Corrected exception handling for checkpoint marker reading error.


Cluster SQL Engine

Added a 'sql.createLuceneIndexForStringValueType' distributed SQL property to disable creation of lucene index by default.


Cluster Storage Engine

Fixed possible failure of background cleanup of dropped SQL indexes.


Cluster Security

Fixed cache group re-encryption after cluster secondary activation.


Diagnostics and Failure Handling

Improved diagnostic capabilities for assertion errors in internal data structures.

Enterprise Edition Changes

Issue ID Category Description


Cluster Security

Fixed an issue that could cause PME freezing during the expiration of thin clients security sessions.


Cluster Data Replication

Fixed wrong sender node detection for nodes in different DR modes in grid during RU.


Cluster Storage Engine

Fixed an issue when a node starts with a WAL archive size over the maxWalArchiveSize setting.


Cluster Communication

Updated Jetty dependency to fix CVE.


Platforms & Thin Clients

.NET: Removed unnecessary code analysis results from the release package.


Cluster Storage Engine

TransactionMXBean parameters now propagate to cluster correctly, including newly joined nodes.


Cluster Data Replication

Improved DR logging to show information on SSL/TLS statuses.

Ultimate Edition Changes

Issue ID Category Description


Cluster Data Snapshots and Recovery

Fixed potential deadlock during snapshot creation.


Cluster Snapshot Utility

Fix an error message when creating a snapshot fails.

Control Center Agent Changes

Issue ID Category Description


Control Center Agent

The cache schema is not sent until the cluster attaches.


Control Center Agent

Old deployment unit versions are now stored in metastore.


Control Center Agent

Fixed an issue with Control Center Agent on zOS systems.


Control Center Agent

Sanitized sensitive information sent to Control Center by Control Center Agent.


Control Center Agent

You can now change Control Center URI without changing Control Center Agent status.

Installation and Upgrade Information

See the Rolling Upgrades page for information about how to perform automated upgrades and for details about version compatibility.

Below is a list of versions that are compatible with the current version. You can rolling-upgrade from any of those. Compatibility with other versions is not guaranteed. If you are on a version that is not listed, contact GridGain for information on upgrade options.

8.7.2-p15, 8.7.3, 8.7.4, 8.7.5, 8.7.5-p1, 8.7.6, 8.7.6-p1, 8.7.7, 8.7.8, 8.7.9, 8.7.10, 8.7.11, 8.7.12, 8.7.13, 8.7.14, 8.7.15, 8.7.16, 8.7.17, 8.7.18, 8.7.19, 8.7.19-p1, 8.7.20, 8.7.21, 8.7.22, 8.7.23, 8.7.24, 8.7.25, 8.7.26, 8.7.26-p1, 8.7.27, 8.7.27-p1, 8.7.28, 8.7.29, 8.7.29-p1, 8.7.30, 8.7.31, 8.7.32, 8.7.33, 8.7.33-p2, 8.7.34, 8.7.35, 8.7.36, 8.7.37, 8.7.38, 8.8.1, 8.8.2, 8.8.3, 8.8.4, 8.8.5, 8.8.6, 8.8.7

Known Limitations

Jetty Configuration Incompatibility in GridGain 8.7.21 and Later

If you are upgrading from version 8.7.20 or earlier, consider an incompatibility issue related to Jetty configuration introduced in GridGain 8.7.21.

Your setup may be affected if:

  • You use the ignite-rest-http module (e.g. to connect to GridGain Web Console)

  • You have a custom Jetty configuration that enables SSL for REST

  • Your Jetty configuration uses the org.eclipse.jetty.util.ssl.SslContextFactory class

  • The keystore specified in the Jetty configuration contains both the CA certificate and the private certificate

In this case, after starting a new version, an exception is thrown with an error message similar to the following:

java.lang.IllegalStateException: KeyStores with multiple certificates are not supported on the base class
org.eclipse.jetty.util.ssl.SslContextFactory. (Use org.eclipse.jetty.util.ssl.SslContextFactory$Server
or org.eclipse.jetty.util.ssl.SslContextFactory$Client instead)

To workaround this issue, alter the Jetty configuration to use org.eclipse.jetty.util.ssl.SslContextFactory$Server or org.eclipse.jetty.util.ssl.SslContextFactory$Client. See the configuration example at the Client Certificate Authentication page.

Default rebalanceThreadPoolSize in GridGain 8.7.26 and Later

In GridGain 8.7.26, the default value of the property IgniteConfiguration.rebalanceThreadPoolSize changed from 1 to min(4, number of CPU / 4). It may cause a compatibility issue under the following conditions:

  • When a Rolling Upgrade is performed

  • The upgrade is performed from 8.5.7 version (or earlier) to 8.5.x or from 8.7.3 (or earlier) to 8.7.x

  • The server nodes have at least 8 CPU cores

  • The nodes configuration does not have the property IgniteConfiguration.rebalanceThreadPoolSize, so the default value is used

In this case, an exception is thrown with an error message similar to the following:

сlass org.apache.ignite.IgniteException: Rebalance configuration mismatch (fix configuration or set -DIGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK=true system property).
Different values of such parameter may lead to rebalance process instability and hanging.  [rmtNodeId=5fc58fb7-209d-489a-8034-0127a81abed6, locRebalanceThreadPoolSize = 4, rmtRebalanceThreadPoolSize = 1]

To workaround this issue, change the configuration of the server nodes to rebalanceThreadPoolSize=1 so that it matches the previous default configuration. For example:

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

    <!-- The rest of the configuration goes here -->

Jetty Doesn’t Accept Incorrect Configuration in GridGain 8.7.31 and Later

In GridGain 8.7.31 Jetty was upgraded to 9.4.33. Starting that version, Jetty has more strict validation of the provided configuration files. Before that version, an incorrectly spelled property in the configuration file had no effect. Starting this version, errors in the configuration will lead to an error on start.

Your setup may be affected if:

  • You use the ignite-rest-http module (e.g. to connect to GridGain Web Console)

  • You have a custom Jetty configuration for REST

  • The custom configuration has errors in it

You will need to fix the custom Jetty configuration before upgrading. No Longer Enables Remote JMX by Default in GridGain 8.7.31 and Later

Starting from 8.7.31 version, GridGain no longer attempts to automatically enable the remote JMX. Default settings are known to cause issues if customized (for example, secure the connection). Also, in most cases, remote JMX is not required since many tools use local JMX connections (not using TCP).

Your setup may be affected if:

  • You start GridGain nodes via script

  • You connect to GridGain nodes' JMX interface remotely over TCP using the default configuration

To continue using remote JMX, you need to manually specify the required JMX settings. Please see the example below. Note that you don’t need remote JMX if you use a local connection, such as connecting JConsole to a GridGain process on the same host.

export JVM_OPTS=" \"


We Value Your Feedback

Your comments and suggestions are always welcome. You can reach us here: or

Please visit the documentation for more information.