Chapter 2. Data Grid Release Information

Learn about new features and get the latest Data Grid release information.

2.1. What’s New in Data Grid 8.1.1

Data Grid 8.1.1 gives you usability and performance improvements and enhances security. Review all the enhancements and updates that are available in 8.1.1.

2.1.1. Data Grid Server

This release includes several enhancements to Data Grid Server.

Customizable Server Filesystem

Data Grid Server now includes system properties that override the default location for folders under the server root directory.

FolderDescriptionSystem property override

/server/conf

Contains server configuration files.

infinispan.server.config.path

/server/data

Contains data files organized by container name.

infinispan.server.data.path

/server/lib

Contains server extension files.
This directory is scanned recursively and used as a classpath.

infinispan.server.lib.path
Separate multiple paths with the following delimiters:
: on Unix / Linux
; on Windows

/server/log

Contains server log files.

infinispan.server.log.path

Set System Properties from File

You can now use set system properties for Data Grid Server from file with the -P and --properties options, for example:

$ ./bin/server.sh -P path/to/system.properties
Run as System Service

Data Grid Server provides system init files so you can run server instances as services on Red Hat Enterprise Linux.

See Run JBoss Data Grid 7 as a RHEL 7 Service (Red Hat Knowledgebase) for more information.

Port Offset Takes Effect for Cluster Transport

When you specify a port offset for Data Grid Server, that port offset now applies to jgroups.bind.port and jgroups.mcast.port.

2.1.2. Data Grid Operator

This release includes several enhancements to Data Grid Operator.

Configuring Anti-Affinity for Data Grid Nodes

Anti-affinity settings protect workloads from single points of failure.

Data Grid Operator provides a spec.affinity field in your Infinispan CR that configures anti-affinity capabilities.

Disable Encryption

You can now disable encryption for client connections.

security:
  endpointEncryption:
          type: None
Install into Multiple Namespaces

As of this release, you can install Data Grid Operator into specific namespaces or multiple namespaces.

2.1.3. Data Grid CLI Configuration

Configure the Command Line Interface (CLI) with command aliases and custom startup properties. You can also define the location on your filesystem where the CLI stores configuration.

2.1.4. Improved Non-Blocking Thread Pool Usage

In previous releases, Data Grid used a Java ThreadPoolExecutor class to manage the blocking thread pool. As of this release, Data Grid replaces ThreadPoolExecutor with an EnhancedQueueExecutor class that allocates new threads only if there are no idle threads. This change improves the efficiency of the non-blocking thread pool usage by ensuring that threads are allocated only when necessary.

2.1.5. ProtoStream API Upgraded

Data Grid 8.1.1 upgrades the ProtoStream API 4.3.4.

Important

In previous versions, the ProtoStream API did not correctly nest message types with the result that the messages were generated as top-level only. For this reason, if you have Protobuf messages in a persistent cache store and upgrade to Data Grid 8.1.1, then you should modify Java classes so that Protobuf annotations are at top-level. This ensures that the nesting in your persisted messages matches the nesting in your Java classes, otherwise data incompatibility issues can occur.

2.1.6. Additions and Amendments to Documentation

Data Grid documentation is updated to include the following content:

2.2. What’s New in Data Grid 8.1.0

Data Grid 8.1.0 improves usability, increases performance, and enhances security. Find out what’s new in 8.1.0.

2.2.1. Cross-Site Replication

Full Support on Red Hat OpenShift

Data Grid cross-site replication is now fully supported with Data Grid Operator. Create global Data Grid clusters on OpenShift that back up across your data centers.

See Configuring Cross-Site Replication on OpenShift.

Conflict Resolution for Asynchronous Backups

Data Grid 8.1 significantly improves asynchronous backups when using cross-site replication capabilities. This release introduces detection for conflicting entries and a resolution mechanism to guarantee data consistency when you have multiple active sites replicating between each other.

Find out complete details and learn how Data Grid detects and resolves conflicts in the documentation.

See Concurrent Writes and Conflicting Entries.

Multiple Site Masters

Data Grid uses JGroups RELAY2 protocol to facilitate inter-cluster communication for cross-site replication. Each cluster has a site master that handle traffic between sites.

Note

Data Grid Operator controls which nodes become site master when using cross-site replication on OpenShift. You cannot modify the RELAY2 configuration with Data Grid Operator.

As of 8.1, you can set multiple site masters in your RELAY2 configuration to balance inter-cluster traffic. Use the max_site_masters attribute as in the following example:

<relay.RELAY2 site="NYC" 1
              max_site_masters="100"/> 2
1
Defines the name of the local site.
2
Specifies the number of site masters. The default value is 1. You can increase the value to any number greater than one. If you set a value that is equal to or greater than the number of nodes in your Data Grid cluster then all nodes act as site masters.

See Setting Up Cross-Site Replication.

2.2.2. Data Grid Server

Data Grid Server 8.1 offers enhanced security and new configuration options.

Automatic Authentication

Data Grid Server uses a default property realm that automatically enforces user authentication on remote endpoints.

See Adding Data Grid Credentials to create usernames and passwords for accessing the Data Grid Console, Command Line Interface (CLI), REST API, or Hot Rod endpoint.

See Securing Access to Data Grid Servers to learn about configuring different authentication mechanisms.

Note

If you installed Data Grid Server 8.0, upgrade to 8.1 and use the configuration schema with default security.

Shared Data Sources for JDBC Cache Stores

Data Grid Server lets you create shared data sources when using JDBC cache stores to persist cache entries to databases.

See Configuring Data Grid Server Data Sources.

Global Roles for Cache Authorization

If you configure cache authorization with role-based access, roles that you declare in the global configuration apply unless you explicitly declare roles in your caches.

<infinispan>
   <cache-container name="default">
      <security>
         <authorization> 1
            <identity-role-mapper/>
            <role name="AdminRole" permissions="ALL"/>
            <role name="ReaderRole" permissions="READ"/>
            <role name="WriterRole" permissions="WRITE"/>
            <role name="SupervisorRole" permissions="READ WRITE EXEC BULK_READ"/>
         </authorization>
      </security>
      <distributed-cache name="secured">
         <security>
            <authorization/> 2
         </security>
      </distributed-cache>
   </cache-container>
   ...
</infinispan>
1
Defines user roles that map to permissions.
2
Implicitly uses all authorization roles in the global configuration.

See Configuring Data Grid Authorization.

2.2.3. Data Grid Command Line Interface (CLI)

Data Grid 8.1 CLI provides additional capabilities for server configuration, user management, and troubleshooting.

User Management

As of 8.1, the CLI provides a user command that replaces the user-tool script included in Data Grid Server distributions.

The user command lets you manage user credentials and groups for property-based security realms. For example, the following commands adds credentials that have "admin" privileges:

[disconnected]> user create myusername --password=qwer1234! --groups=admin

See Adding Data Grid Credentials.

Logging Configuration

You can now modify server logging configuration at runtime. For example, to enable DEBUG log messages for the org.infinispan category:

[hostname@cluster//containers/default]> logging set --level=DEBUG org.infinispan

See Changing Data Grid Server Logging Configuration at Runtime.

Diagnostic Reports

Data Grid Server provides an aggregate log that includes information, such as thread dumps, memory configuration, and open sockets, that you can use to monitor and troubleshoot deployments.

Use the report command with the CLI as in the following example:

[hostname@cluster//containers/default]> server report
Downloaded report 'infinispan-hostname-timestamp-report.tar.gz'

See Getting Diagnostic Reports for Data Grid Servers.

Note

Diagnostics reports for Data Grid Server are currently available on Linux/ Unix systems only.

2.2.4. Data Grid Console

Data Grid 8.1 Console provides additional capabilities such as:

  • Creating and deleting cache entries.
  • Cross site replication management.
  • Schema management.
  • Searching the data container with Ickle queries.
  • Integration with Red Hat SSO so that accessing Data Grid Console obtains credentials through the realm login page.

For information on accessing the Data Grid Console and creating caches, see Creating Caches with the Data Grid Console.

2.2.5. REST API

Calling the Data Grid REST API with the ?action URL parameter is now supported with the POST method. Calls return status 200 if responses contain content or status 204 if not.

Support for the ?action URL parameter with the GET method is planned for removal.

2.2.6. Hot Rod Java Clients

Configuration via URI

Hot Rod Java Client configuration now supports URI in the following format:

hotrod[s]://[user[:password]@]host[:port][,host2[:port]][?property=value[&property2=value2]]

This provides a more compact way for configuring your Hot Rod Java client connections. See Hot Rod Client Configuration.

Per-Cache Configuration with Automatic Cache Creation

When Hot Rod Java clients attempt to access caches that do not exist, they return null for getCache("<cache_name>") invocations. You can change this default behavior so that clients automatically create caches on first access using caches configuration templates or Data Grid cache definitions in XML format.

See Creating Caches on First Access.

2.2.7. Data Grid Queries

Data Grid indexing and querying capabilities have undergone changes that decrease configuration overhead and offer better performance when searching the data store.

Major changes include:

  • Deprecation of the Data Grid Lucene Directory.
  • Deprecation of the org.infinispan.query.SearchManager interface.

Data Grid no longer supports native objects for Apache Lucene and Hibernate Search. Use the org.infinispan.query.Search class as your entry point for string-based searches with the Ickle query language.

Important

You should plan to migrate any usage of deprecated search functionality, including Lucene-based queries, and start using the org.infinispan.query.Search class as an entry point for performing searches with the Ickle query language.

See the following:

2.2.8. Simplified Configuration

Data Grid 8.1 deprecates several configuration attributes to streamline user options and improve consistency between declarative and programmatic settings.

memory configuration is the most notable change in Data Grid 8.1. It lets you configure the data container to:

  • Store entries in the JVM heap or in off-heap memory.
  • Control the size of the data container. You can set a maximum number of entries that caches can hold or set a maximum amount of memory that caches can use.

As in previous releases, the memory configuration can also configure Data Grid to store entries in binary format. However, as of 8.1, binary storage configuration is deprecated. Instead you should define the encoding for caches. If you want to use binary storage, specify the MediaType for any binary format in your cache definition.

2.2.9. Non-Blocking I/0

Data Grid consolidates thread pools into two:

  • Non-blocking thread pool
  • Blocking thread pool

As of this release, nearly all Data Grid internal components use the non- blocking thread pool, which increases throughput, reduces latency, and improves overall responsiveness for heavy I/O workloads.

Any blocking I/O paths, now use the blocking thread pool to avoid holding up non-blocking calls.

NonBlockingStore SPI

Data Grid 8.1 introduces the NonBlockingStore interface for implementing persistent cache stores. As the name implies NonBlockingStore SPI exposes methods that must never block the invoking thread.

To handle blocking operations, Data Grid provides a BlockingManager utility class.

See the following:

2.2.10. Red Hat JBoss EAP Modules

Data Grid Modules for Red Hat JBoss EAP provide a temporary solution until planned functionality for Red Hat JBoss EAP to directly manage the infinispan subsystem is available.

See Data Grid Modules for Red Hat JBoss EAP.

2.3. Supported Java versions in Data Grid 8.1

Red Hat supports different Java versions, depending on how you install Data Grid.

Embedded caches

Red Hat supports Java 8 and Java 11 when using Data Grid for embedded caches in custom applications.

Remote caches

Red Hat supports Java 11 only for Data Grid Server installations. For Hot Rod Java clients, Red Hat supports Java 8 and Java 11.

Java 8 deprecation

Support for Java 8 is deprecated in the next release, Data Grid 8.2, and currently planned for removal in Data Grid 8.4.

Users with embedded caches in custom applications should plan to upgrade to Java 11 or to Java 17 when support becomes available.

Hot Rod Java clients running in applications that require Java 8 can continue using older versions of client libraries. Red Hat supports using older Hot Rod Java client versions in combination with the latest Data Grid Server version.