Chapter 1. Data Grid release information

Data Grid 8.3 offers full support for Java 17 for embedded and remote caches.

Data Grid 8.3 introduces a Helm chart for deploying Data Grid clusters on Red Hat OpenShift. The Data Grid Helm chart provides an alternative for scenarios where it is not possible to deploy clusters that the Data Grid Operator manages, or where you require manual configuration, deployment, and management of Data Grid clusters.

The Data Grid Helm chart includes deploy.infinispan values that let you apply custom configuration to Data Grid Server nodes with the Helm client or through the OpenShift Web Console.

Data Grid provides declarative and programmatic configuration attributes for customizing caches and underlying mechanisms such as security and cluster transport.

Polyglot configuration

Data Grid 8.3 lets you create declarative configuration in JSON and YAML format in addition to XML. You can re-use the same Data Grid configuration files for any deployment platform: Red Hat Enterprise Linux (RHEL) or Red Hat OpenShift via Data Grid Operator or the Data Grid Helm chart.

Mutable configuration attributes for dynamic caches

Data Grid 8.3 lets you modify certain configuration attributes for caches that you create dynamically at runtime. This means you longer need to delete and then recreate caches to change configuration attributes such as lifespan for expiration or max-count for eviction.

Changes to cache configuration must be compatible with the existing configuration. For example you cannot modify cache configuration to change the replicated-cache element to distributed-cache or use the max-count attribute instead of the max-size attribute.

For usage details, see the CLI or REST sections.

Cache size statistics

As of Data Grid 8.3, the currentNumberOfEntries statistic returns -1 by default to improve performance.

Data Grid also now provides an accurate-size attribute for metrics configuration if you want to restore accurate values for this statistic. However this is a resource-intensive calculation and is recommended for development environments only. Set the value to true as follows:

<cache-container>
 <metrics accurate-size="true"/>
</cache-container>

<cache-container>
 <metrics accurate-size="true"/>
</cache-container>

GlobalConfigurationBuilder b = new GlobalConfigurationBuilder();
b.metrics().accurateSize(true);

GlobalConfigurationBuilder b = new GlobalConfigurationBuilder();
b.metrics().accurateSize(true);

Data Grid 8.3 provides new and improved cache store implementations for using persistent storage.

Default file-based cache store implementation

To improve performance by using less memory resources and avoiding fragmentation, SoftIndexFileStore is now the default implementation for file-based cache stores in Data Grid. As of 8.3, including file-store persistence in cache configuration creates a soft index file-based cache store instead of a single-file cache store.

Data Grid automatically migrates any file-store configuration to a SoftIndexFileStore when you upgrade to 8.3.

If you are migrating to Data Grid 8.3 from an earlier version and your cache configuration includes the soft-index-file-store element, you should convert it to the file-store element. For more information, see Migrating to Data Grid 8.

<persistence>
  <soft-index-file-store xmlns="urn:infinispan:config:soft-index:12.1">
    <index path="testCache/index" />
    <data path="testCache/data" />
  </soft-index-file-store>
</persistence>

<persistence>
  <soft-index-file-store xmlns="urn:infinispan:config:soft-index:12.1">
    <index path="testCache/index" />
    <data path="testCache/data" />
  </soft-index-file-store>
</persistence>

<persistence>
  <file-store>
    <index path="testCache/index" />
    <data path="testCache/data" />
  </file-store>
</persistence>

<persistence>
  <file-store>
    <index path="testCache/index" />
    <data path="testCache/data" />
  </file-store>
</persistence>

SQL cache store

Data Grid 8.3 introduces the SQL cache store that simplifies access to data in persistent storage and pre-loads caches through JDBC connections.

You can create two types of SQL cache store:

JDBC connection factories

As of Data Grid 8.3 Data Grid provides ConnectionFactory implementations for JDBC connections in the org.infinispan.persistence.jdbc.common.configuration package. You can use these connection factories with SQL cache stores and JDBC string-based caches stores.

Data Grid Server runs in a dedicated Java Virtual Machine (JVM) and provides scalable and fault tolerant clusters for remote caches.

Distributed security realms

Data Grid Server now lets you combine multiple security realms into a single realm. When authenticating users, Data Grid Server uses each security realm in turn until it finds one that can perform the authentication.

For example, the following security realm includes an LDAP realm and a property realm and the distributed-realm element:

<security-realms>
   <security-realm name="my-distributed-realm">
      <ldap-realm>
         <!-- LDAP realm configuration. -->
      </ldap-realm>
      <properties-realm>
         <!-- Property realm configuration. -->
      </properties-realm>
      <distributed-realm/>
   </security-realm>
</security-realms>

<security-realms>
   <security-realm name="my-distributed-realm">
      <ldap-realm>
         <!-- LDAP realm configuration. -->
      </ldap-realm>
      <properties-realm>
         <!-- Property realm configuration. -->
      </properties-realm>
      <distributed-realm/>
   </security-realm>
</security-realms>

Multiple endpoint configuration

You can configure Data Grid Server to bind multiple endpoints to different sockets and use different security realms.

The following snippet, as an example, contains two different endpoint configurations. One endpoint binds to a "public" socket, uses an "application" security realm, and disables administrative features. Another endpoint binds to a "private" socket, uses a "management" security realm, and enables administrative features.

<endpoints>
  <endpoint socket-binding="public"
            security-realm="application"
            admin="false">
    <hotrod-connector/>
    <rest-connector/>
  </endpoint>
  <endpoint socket-binding="private"
            security-realm="management">
    <hotrod-connector/>
    <rest-connector/>
  </endpoint>
</endpoints>

<endpoints>
  <endpoint socket-binding="public"
            security-realm="application"
            admin="false">
    <hotrod-connector/>
    <rest-connector/>
  </endpoint>
  <endpoint socket-binding="private"
            security-realm="management">
    <hotrod-connector/>
    <rest-connector/>
  </endpoint>
</endpoints>

Security enhancements

<cache-container>
  <transport server:security-realm="tls-transport"/>
</cache-container>

<cache-container>
  <transport server:security-realm="tls-transport"/>
</cache-container>

<engine enabled-protocols="TLSv1.3" />

<engine enabled-protocols="TLSv1.3" />

Configuration overlays

Data Grid Server can parse multiple configuration files that you overlay on startup with repeated --server-config= or -c arguments.

bin/server.sh -c infinispan.xml -c overlay.yaml

$ bin/server.sh -c infinispan.xml -c overlay.yaml

You can use as many configuration overlay files as required, in any order. Configuration overlay files:

Overlay files cannot contain cache configuration fragments. For example, to create distributed cache in an overlay file, -c mycache.yaml, you must include the infinispan and cacheContainer fields as follows:

infinispan:
  cacheContainer:
    distributedCache:
      name: "mycache"
      mode: "SYNC"
      owners: 2
      statistics: "true"
      encoding:
        mediaType: "application/x-protostream"

infinispan:
  cacheContainer:
    distributedCache:
      name: "mycache"
      mode: "SYNC"
      owners: 2
      statistics: "true"
      encoding:
        mediaType: "application/x-protostream"

Listening on all addresses

If you specify the 0.0.0.0 meta-address (INADDR_ANY) as the bind address for Data Grid Server, it listens for incoming client connections on all available network interfaces.

Performance and usability improvements

Data Grid Console is a graphical user interface for monitoring and managing remote caches that includes the following features and enhancements in 8.3:

The Data Grid CLI lets you script and automate administrative operations for remote caches.

Modifying configuration attributes at runtime

The alter command lets you modify Data Grid configuration attributes at runtime.

alter cache mycache --attribute=clustering.remote-timeout --value=5000

alter cache mycache --attribute=clustering.remote-timeout --value=5000

Controlling cache availability

The availability command lets you manage availability of clustered caches in network partitions.

availability --mode=AVAILABLE mycache

availability --mode=AVAILABLE mycache

Enabling and disabling rebalancing operations

The rebalance command lets you turn cluster rebalancing operations for caches on and off.

Hot Rod cluster migration

The migrate command provides additional options for migrating data from one running Data Grid cluster to another.

Retrieving cross-site replication relay nodes

The site command lets you find out which nodes in the Data Grid cluster handle RELAY messages for cross-site replication.

Native CLI

The native CLI is updated in 8.3 to improve usage as an oc client plugin and for interacting with Data Grid pods running on Red Hat OpenShift.

Data Grid gives you access to remote caches and containers with HTTP over REST.

Modifying configuration attributes at runtime

Controlling cache availability

Enabling and disabling rebalancing operations

Hot Rod migration

The REST API exposes controls that let you migrate data from one running Data Grid cluster to another.

Retrieving cross-site replication relay nodes

Converting cache configuration between XML, JSON, and YAML

Invoke a POST request with valid configuration and the ?action=convert parameter. Data Grid responds with the equivalent representation of the configuration in the type specified by the Accept header.

POST /rest/v2/caches?action=convert

POST /rest/v2/caches?action=convert

Cache entry and cache configuration listeners with server-sent events

Data Grid lets you index caches and perform relational or full-text queries with in the Ickle query language.

Delete by query

You can delete entries from Data Grid caches with the following syntax:

DELETE FROM <entityName> [WHERE condition]

DELETE FROM <entityName> [WHERE condition]

Query execution methods

The Query API provides two methods for executing Ickle queries on a cache:

Cross-site replication lets you back up Data Grid clusters across multiple geographic regions.

Improved observability and metrics

Data Grid 8.3 updates cross-site replication capabilities to improve monitoring and statistics.

Data Grid lets you:

Data Grid 8.3 also provides more detailed metrics about cross-site replication operations for each backup location and for caches, including response times and number of RELAY messages.

Naming global clusters

The cluster attribute lets you define a name for global clusters that is printed to log messages. This makes it easier to distinguish global clusters from local clusters in Data Grid logs.

By default cross-site clusters are named "xsite" but you can specify a custom name, such as "my-global-cluster" in the following example:

<remote-sites default-stack="tcp" cluster="my-global-cluster">
  <remote-site name="LON"/>
  <remote-site name="NYC"/>
</remote-sites>

<remote-sites default-stack="tcp" cluster="my-global-cluster">
  <remote-site name="LON"/>
  <remote-site name="NYC"/>
</remote-sites>

Data Grid 8.3 simplifies the configuration and mechanisms for performing live migration of data across clusters to move from one version to another. Rolling upgrades in Data Grid 8.3: