Apache Ignite 2.18 Release: What's New

We are happy to announce the release of Apache Ignite 2.18.0! In this version, the Ignite community has removed the @IgniteExperimental annotation from a huge number of components, introduced a range of new features and system views. Made improvements to deliver a more efficient, flexible, and future-proof platform. Below, we'll cover the key highlights that you can look forward to when upgrading to the new release.

Support ability to configure persistence folder for DataRegion​

Initially, Apache Ignite allowed to configure single root folder for persistence data via:

DataStorageConfiguration#setStoragePath

In case when specific server has several storage devices there was no way to use them all without complex operations with symlinks and file moving. Now it`s possible to provide ability to configure multiple storagePaths per DataRegion.

new DataStorageConfiguration()
    .setExtraStoragePaths("/path1", "/path2");

Count of inserted and removed bytes per cache​

Apache Ignite provides multiple metrics for:

• Transactions.
• Thread Pools.
• Cache Group IO.
• ... And so on

An additional metric that counts the total size (in bytes) of entries inserted into and removed from a cache group since the last cluster restart has been introduced. These metrics help to estimate approximate memory usage for in-memory caches, where direct byte-size calculation is problematic:
insertedBytes - Shows the count of inserted to store bytes.
removedBytes - Shows the count of removed from store bytes.

SessionContext API​

This new API implements IEP-129 by introducing a mechanism that provides session context and application attributes within Apache Ignite.

The proposal addresses the following scenarios:

• An application acquires an Ignite connection from a pool and needs to specify attributes that business logic depends on (e.g., for audit trails or multi-language support).
• Different applications reuse the same connection but require their own attribute values.

Accessing attributes via SessionContext

• The new SessionContext interface provides a single entry point for attributes across all levels and session data.
• Developers inject the SessionContextProviderResource into their functions (e.g., QuerySqlFunction, CacheInterceptor) to access the current context.
• The provider extracts the SessionContext from the Ignite thread without requiring new instances per call.

Set through jdbc:

// JDBC connection to Ignite server.
try (Connection conn = DriverManager.getConnection(URL)) {
    conn.setClientInfo("SESSION_ID", "111-333");

    ...
}

Obtain through user defined function:

@SessionContextProviderResource
public SessionContextProvider sesCtxProv;

@QuerySqlFunction
public @Nullable String sessionId() {
    return sesCtxProv.getSessionContext().getAttribute("SESSION_ID");
}

User defined table functions are available in calcite sql engine​

Let`s define function like:

@QuerySqlTableFunction(columnTypes = {int.class, int.class, int.class}, columnNames = {"COL_1", "COL_2", "COL_3"})
public static Iterable<Collection<?>> collectionRow(int x) {
    return Arrays.asList(
        Arrays.asList(x + 1, x + 2, x + 3),
        Arrays.asList(x + 4, x + 5, x + 6),
        Arrays.asList(x + 7, x + 8, x + 9)
    );
}

And now it available to use:

sql("SELECT * from collectionRow(10)")

Ignite cluster over multiple data centers optimizations​

Modern requirements dictate the ability to stretch a cluster across multiple data centers.
At the same time, the following requirements must be met:

• Minimal additional configuration.
• Connectivity should work seamlessly, exactly as with a standard cluster.
• The cluster must survive a complete DC failure.
• Minimize inter-DC communication.

Numerous optimizations have been performed:

• Clients connect to servers within their own DC. Supported in the thin client.
• KV operations read from the local DC. Supported in the thin client.
• The discovery mechanism minimizes cross-DC connections between nodes.
• Data rebalancing should prioritize pulling partitions from within the same DC (localizing rebalance traffic within each DC).
• Minimize cross-DC communication during snapshot recovery.
• SQL (Calcite) should fetch data from the local DC.

A new property dataCenterId (node DC) has also been added. It can be checked through the NODES view for server nodes and in the metrics for the fat client.

Anything else?​

See the release notes to learn about all of the new features and improvements.

Reach out to us on the community user list for more questions, details, and feedback.

Sincerely yours, Ignite contributors and committers