Este conteúdo não está disponível no idioma selecionado.
Chapter 3. Migrating Data Grid configuration
Find changes to Data Grid configuration that affect migration to Data Grid 8.
3.1. Data Grid cache configuration Copiar o linkLink copiado para a área de transferência!
Data Grid 8 provides empty cache containers by default. When you start Data Grid, it instantiates a cache manager so you can create caches at runtime.
However, in comparison with previous versions, there is no "default" cache out of the box.
In Data Grid 8, caches that you create through the CacheContainerAdmin API are permanent to ensure that they survive cluster restarts.
Permanent caches
.administration()
.withFlags(AdminFlag.PERMANENT)
.getOrCreateCache("myPermanentCache", "org.infinispan.DIST_SYNC");
.administration()
.withFlags(AdminFlag.PERMANENT)
.getOrCreateCache("myPermanentCache", "org.infinispan.DIST_SYNC");
- 1
AdminFlag.PERMANENTis enabled by default to ensure that caches survive restarts.
You do not need to set this flag when you create caches. However, you must separately add persistent storage to Data Grid for data to survive restarts, for example:
ConfigurationBuilder b = new ConfigurationBuilder();
b.persistence()
.addSingleFileStore()
.location("/tmp/myDataStore")
.maxEntries(5000);
ConfigurationBuilder b = new ConfigurationBuilder();
b.persistence()
.addSingleFileStore()
.location("/tmp/myDataStore")
.maxEntries(5000);
Volatile caches
.administration()
.withFlags(AdminFlag.VOLATILE)
.getOrCreateCache("myTemporaryCache", "org.infinispan.DIST_SYNC");
.administration()
.withFlags(AdminFlag.VOLATILE)
.getOrCreateCache("myTemporaryCache", "org.infinispan.DIST_SYNC");
Data Grid 8 provides cache templates for server installations that you can use to create caches with recommended settings.
You can get a list of available cache templates as follows:
Use
Tabauto-completion with the CLI:[//containers/default]> create cache --template=
[//containers/default]> create cache --template=Copy to Clipboard Copied! Toggle word wrap Toggle overflow Use the REST API:
GET 127.0.0.1:11222/rest/v2/cache-managers/default/cache-configs/templates
GET 127.0.0.1:11222/rest/v2/cache-managers/default/cache-configs/templatesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.1. Cache encoding Copiar o linkLink copiado para a área de transferência!
When you create remote caches you should configure the MediaType for keys and values. Configuring the MediaType guarantees the storage format for your data.
To encode caches, you specify the MediaType in your configuration. Unless you have others requirements, you should use ProtoStream, which stores your data in a language-neutral, backwards compatible format.
<encoding media-type="application/x-protostream"/>
Distributed cache configuration with encoding
If you do not encode remote caches, Data Grid Server logs the following message:
WARN (main) [org.infinispan.encoding.impl.StorageConfigurationManager] ISPN000599: Configuration for cache 'mycache' does not define the encoding for keys or values. If you use operations that require data conversion or queries, you should configure the cache with a specific MediaType for keys or values.
WARN (main) [org.infinispan.encoding.impl.StorageConfigurationManager] ISPN000599: Configuration for cache 'mycache' does not define the encoding for keys or values. If you use operations that require data conversion or queries, you should configure the cache with a specific MediaType for keys or values.
In a future version, cache encoding will be required for operations where data conversion takes place; for example, cache indexing and searching the data container, remote task execution, reading and writing data in different formats from the Hot Rod and REST endpoints, as well as using remote filters, converters, and listeners.
3.1.2. Cache health status Copiar o linkLink copiado para a área de transferência!
Data Grid 7.x includes a Health Check API that returns health status of the cluster as well as caches within it.
Data Grid 8 also provides a Health API. For embedded and server installations, you can access the Health API via JMX with the following MBean:
org.infinispan:type=CacheManager,name="default",component=CacheContainerHealth
org.infinispan:type=CacheManager,name="default",component=CacheContainerHealth
Data Grid Server also exposes the Health API through the REST endpoint and the Data Grid Console.
| 7.x | 8.x | Description |
|---|---|---|
|
|
| Indicates a cache is operating as expected. |
|
|
| Indicates a cache is in the rebalancing state but otherwise operating as expected. |
|
|
| Indicates a cache is not operating as expected and possibly requires troubleshooting. |
| N/A |
| Added in 8.2 to indicate that a cache could not start with the supplied configuration. |
3.1.3. Changes to the Data Grid 8.1 configuration schema Copiar o linkLink copiado para a área de transferência!
This topic lists changes to the Data Grid configuration schema between 8.0 and 8.1.
New and modified elements and attributes
-
stackadds support for inline JGroups stack definitions. -
stack.combineandstack.positionattributes let you override and modify JGroups stack definitions. -
metricslets you configure how Data Grid exports metrics that are compatible with the Eclipse MicroProfile Metrics API. -
context-initializerlets you specify aSerializationContextInitializerimplementation that initializes a Protostream-based marshaller for user types. -
key-transformerslets you register transformers that convert custom keys to String for indexing with Lucene. -
statisticsnow defaults to "false".
Deprecated elements and attributes
The following elements and attributes are now deprecated:
-
address-countattribute for theoff-heapelement. -
protocolattribute for thetransactionelement. -
duplicate-domainsattribute for thejmxelement. -
advanced-externalizer -
custom-interceptors -
state-transfer-executor -
transaction-protocol
Removed elements and attributes
The following elements and attributes were deprecated in a previous release and are now removed:
-
deadlock-detection-spin -
compatibility -
write-skew -
versioning -
data-container -
eviction -
eviction-thread-policy
3.1.4. Changes to the Data Grid 8.2 configuration schema Copiar o linkLink copiado para a área de transferência!
This topic lists changes to the Data Grid configuration schema between 8.1 and 8.2.
Modified elements and attributes
-
white-listchanges toallow-list -
roleis now a sub-element ofrolesfor defined user roles and permissions for security authorization. -
context-initializeris updated for automaticSerializationContextInitializerregistration.
If your configuration does not containcontext-initializerelements then thejava.util.ServiceLoadermechanism automatically discovers allSerializationContextInitializerimplementations on the classpath and loads them. -
Default value of the
minOccursattribute changes from0to1for theindexed-entityelement.
New elements and attributes
-
propertyattribute added to thetransportelement that lets you pass name/value transport properties. -
cache-sizeandcache-timeoutattributes added to thesecurityelement to configure the size and timeout for the Access Control List (ACL) cache. -
index-reader,index-writer, andindex-mergechild elements added to theindexingelement. -
storageattribute added to theindexingelement that specifies index storage options. -
pathattribute added to theindexingelement that specifies a directory when using file system storage for the index. -
bias-acquisitionattribute added to thescattered-cacheelement that controls when nodes can acquire a bias on an entry. -
bias-lifespanattribute added to thescattered-cacheelement that specifies, in milliseconds, how long nodes can keep an acquired bias. -
merge-policyattribute added to thebackupselement that specifies an algorithm for resolving conflicts with cross-site replication. -
modeattribute added to thestate-transferchild element for thebackup.
Themodeattribute configures whether cross-site replication state transfer happens manually or automatically. -
INSERT_ABOVE,INSERT_BEFORE, andINSERT_BELOWattributes added to thestack.combineattribute for extending JGroups stacks with inheritance.
Deprecated elements and attributes
No elements or attributes are deprecated in Data Grid 8.2.
Removed elements and attributes
No elements or attributes are removed in Data Grid 8.2.
3.1.5. Changes to the Data Grid 8.3 configuration schema Copiar o linkLink copiado para a área de transferência!
This topic lists changes to the Data Grid configuration schema between 8.2 and 8.3.
Schema changes
-
urn:infinispan:config:store:soft-indexnamespace is no longer available.
Modified elements and attributes
-
file-storeelement in theurn:infinispan:confignamespace defaults to using soft-index file cache stores. -
single-file-storeelement is included in theurn:infinispan:confignamespace but is now deprecated.
New elements and attributes
-
indexanddataelements are now available to configure how Data Grid stores indexes and data for file-based cache stores with thefile-storeelement. -
open-files-limitandcompaction-thresholdattributes for thefile-storeelement. clusterattribute added to theremote-sitesandremote-siteelements that lets you define global cluster names for cross-site communication.NoteGlobal cluster names that you specify with the
clusterattribute must be the same at all sites.accurate-sizeattribute added to themetricselement to enable calculations of the data set with thecurrentNumberOfEntriesstatistic.ImportantAs of Data Grid 8.3 the
currentNumberOfEntriesstatistic returns a value of-1by default because it is an expensive operation to perform.-
touchattribute added to theexpirationelement that controls how timestamps get updated for entries in clustered caches with maximum idle expiration. The default value isSYNCand the attribute applies only to caches that use synchronous replication. Timestamps are updated asynchronously for caches that use asynchronous replication. lifespanattribute added to thestrong-counterfor attaching expiration values, in milliseconds. The default value is-1which means strong consistent counters never expire.NoteThe
lifespanattribute for strong counters is currently available as a Technology Preview.
Deprecated elements and attributes
The following elements and attributes are now deprecated:
-
single-file-storeelement. -
max-entriesandpathattributes for thefile-storeelement.
Removed elements and attributes
The following elements and attributes are no longer available in the Data Grid schema:
-
remote-command-executorattribute for thetransportelement. -
capacityattribute for thedistributed-cacheelement.
3.1.6. Changes to the Data Grid 8.4 configuration schema Copiar o linkLink copiado para a área de transferência!
This topic lists changes to the Data Grid configuration schema between 8.3 and 8.4.
Schema changes
New elements and attributes
-
default-max-resultsattribute added to thequeryelement that lets you limits the number of results returned by a query. Applies to indexed, non-indexed, and hybrid queries. -
startup-modeattribute that lets you define which operation should Data Grid perform when the cache starts. The options arepurge,reindex,autoornone. The default value isnone. -
raft-membersattribute that lets you define a list of raft members separated by space.
Deprecated elements and attributes
The following elements and attributes are now deprecated:
-
scattered-cacheelement is now deprecated
Removed elements and attributes
The following elements and attributes are no longer available in the Data Grid schema:
-
fetch-statestore property is no longer available. You can remove the attribute from your xml configuration.
3.2. Eviction configuration Copiar o linkLink copiado para a área de transferência!
Data Grid 8 simplifies eviction configuration in comparison with previous versions. However, eviction configuration has undergone numerous changes across different Data Grid versions, which means migration might not be straightforward.
As of Data Grid 7.2, the memory element replaces the eviction element in the configuration. This section refers to eviction configuration with the memory element only. For information on migrating configuration that uses the eviction element, refer to the Data Grid 7.2 documentation.
3.2.1. Storage types Copiar o linkLink copiado para a área de transferência!
Data Grid lets you control how to store entries in memory, with the following options:
- Store objects in JVM heap memory.
- Store bytes in native memory (off-heap).
- Store bytes in JVM heap memory.
Changes in Data Grid 8
In previous 7.x versions, and 8.0, you use object, binary, and off-heap elements to configure the storage type.
Starting with Data Grid 8.1, you use a storage attribute to store objects in JVM heap memory or as bytes in off-heap memory.
To store bytes in JVM heap memory, you use the encoding element to specify a binary storage format for your data.
| Data Grid 7.x | Data Grid 8 |
|---|---|
|
|
|
|
|
|
|
|
|
Object storage in Data Grid 8
By default, Data Grid 8.1 uses object storage (JVM heap):
<distributed-cache> <memory /> </distributed-cache>
<distributed-cache>
<memory />
</distributed-cache>
You can also configure storage="HEAP" explicitly to store data as objects in JVM heap memory:
<distributed-cache> <memory storage="HEAP" /> </distributed-cache>
<distributed-cache>
<memory storage="HEAP" />
</distributed-cache>
Off-heap storage in Data Grid 8
Set "OFF_HEAP" as the value of the storage attribute to store data as bytes in native memory:
<distributed-cache> <memory storage="OFF_HEAP" /> </distributed-cache>
<distributed-cache>
<memory storage="OFF_HEAP" />
</distributed-cache>
Off-heap address count
In previous versions, the address-count attribute for offheap lets you specify the number of pointers that are available in the hash map to avoid collisions. With Data Grid 8.1, address-count is no longer used and off-heap memory is dynamically re-sized to avoid collisions.
Binary storage in Data Grid 8
Specify a binary storage format for cache entries with the encoding element:
<distributed-cache> <!--Configure MediaType for entries with binary formats.--> <encoding media-type="application/x-protostream"/> <memory ... /> </distributed-cache>
<distributed-cache>
<!--Configure MediaType for entries with binary formats.-->
<encoding media-type="application/x-protostream"/>
<memory ... />
</distributed-cache>
As a result of this change, Data Grid no longer stores primitives and String mixed with byte[], but stores only byte[].
3.2.2. Eviction threshold Copiar o linkLink copiado para a área de transferência!
Eviction lets Data Grid control the size of the data container by removing entries when the container becomes larger than a configured threshold.
In Data Grid 7.x and 8.0, you specify two eviction types that define the maximum limit for entries in the cache:
-
COUNTmeasures the number of entries in the cache. -
MEMORYmeasures the amount of memory that all entries in the cache take up.
Depending on the configuration you set, when either the count or the total amount of memory exceeds the maximum, Data Grid removes unused entries.
Data Grid 7.x and 8.0 also use the size attribute that defines the size of the data container as a long. Depending on the storage type you configure, eviction occurs either when the number of entries or amount of memory exceeds the value of the size attribute.
With Data Grid 8.1, the size attribute is deprecated along with COUNT and MEMORY. Instead, you configure the maximum size of the data container in one of two ways:
-
Total number of entries with the
max-countattribute. -
Maximum amount of memory, in bytes, with the
max-sizeattribute.
Eviction based on total number of entries
<distributed-cache> <memory max-count="..." /> </distributed-cache>
<distributed-cache>
<memory max-count="..." />
</distributed-cache>
Eviction based on maximum amount of memory
<distributed-cache> <memory max-size="..." /> </distributed-cache>
<distributed-cache>
<memory max-size="..." />
</distributed-cache>
3.2.3. Eviction strategies Copiar o linkLink copiado para a área de transferência!
Eviction strategies control how Data Grid performs eviction.
Data Grid 7.x and 8.0 let you set one of the following eviction strategies with the strategy attribute:
| Strategy | Description |
|---|---|
|
| Data Grid does not evict entries. This is the default setting unless you configure eviction. |
|
| Data Grid removes entries from memory so that the cache does not exceed the configured size. This is the default setting when you configure eviction. |
|
|
Data Grid does not perform eviction. Eviction takes place manually by invoking the |
|
|
Data Grid does not write new entries to the cache if doing so would exceed the configured size. Instead of writing new entries to the cache, Data Grid throws a |
With Data Grid 8.1, you can use the same strategies as in previous versions. However, the strategy attribute is replaced with the when-full attribute.
<distributed-cache> <memory when-full="<eviction_strategy>" /> </distributed-cache>
<distributed-cache>
<memory when-full="<eviction_strategy>" />
</distributed-cache>
Eviction algorithms
With Data Grid 7.2, the ability to configure eviction algorithms was deprecated along with the Low Inter-Reference Recency Set (LIRS).
From version 7.2 onwards, Data Grid includes the Caffeine caching library that implements a variation of the Least Frequently Used (LFU) cache replacement algorithm known as TinyLFU. For off-heap storage, Data Grid uses a custom implementation of the Least Recently Used (LRU) algorithm.
3.2.4. Eviction configuration comparison Copiar o linkLink copiado para a área de transferência!
Compare eviction configuration between different Data Grid versions.
Object storage and evict on number of entries
7.2 to 8.0
<memory> <object size="1000000" eviction="COUNT" strategy="REMOVE"/> </memory>
<memory>
<object size="1000000" eviction="COUNT" strategy="REMOVE"/>
</memory>
8.1
<memory max-count="1MB" when-full="REMOVE"/>
<memory max-count="1MB" when-full="REMOVE"/>
Object storage and evict on amount of memory
7.2 to 8.0
<memory> <object size="1000000" eviction="MEMORY" strategy="MANUAL"/> </memory>
<memory>
<object size="1000000" eviction="MEMORY" strategy="MANUAL"/>
</memory>
8.1
<memory max-size="1MB" when-full="MANUAL"/>
<memory max-size="1MB" when-full="MANUAL"/>
Binary storage and evict on number of entries
7.2 to 8.0
<memory> <binary size="500000000" eviction="MEMORY" strategy="EXCEPTION"/> </memory>
<memory>
<binary size="500000000" eviction="MEMORY" strategy="EXCEPTION"/>
</memory>
8.1
<cache> <encoding media-type="application/x-protostream"/> <memory max-size="500 MB" when-full="EXCEPTION"/> </cache>
<cache>
<encoding media-type="application/x-protostream"/>
<memory max-size="500 MB" when-full="EXCEPTION"/>
</cache>
Binary storage and evict on amount of memory
7.2 to 8.0
<memory> <binary size="500000000" eviction="COUNT" strategy="MANUAL"/> </memory>
<memory>
<binary size="500000000" eviction="COUNT" strategy="MANUAL"/>
</memory>
8.1
<memory max-count="500 MB" when-full="MANUAL"/>
<memory max-count="500 MB" when-full="MANUAL"/>
Off-heap storage and evict on number of entries
7.2 to 8.0
<memory> <off-heap size="10000000" eviction="COUNT"/> </memory>
<memory>
<off-heap size="10000000" eviction="COUNT"/>
</memory>
8.1
<memory storage="OFF_HEAP" max-count="10MB"/>
<memory storage="OFF_HEAP" max-count="10MB"/>
Off-heap storage and evict on amount of memory
7.2 to 8.0
<memory> <off-heap size="1000000000" eviction="MEMORY"/> </memory>
<memory>
<off-heap size="1000000000" eviction="MEMORY"/>
</memory>
8.1
<memory storage="OFF_HEAP" max-size="1GB"/>
<memory storage="OFF_HEAP" max-size="1GB"/>
3.3. Expiration configuration Copiar o linkLink copiado para a área de transferência!
Expiration removes entries from caches based on their lifespan or maximum idle time.
When migrating your configuration from Data Grid 7.x to 8, there are no changes that you need to make for expiration. The configuration remains the same:
Lifespan expiration
<expiration lifespan="1000" />
<expiration lifespan="1000" />
Max-idle expiration
<expiration max-idle="1000" interval="120000" />
<expiration max-idle="1000" interval="120000" />
For Data Grid 7.2 and earlier, using max-idle with clustered caches had technical limitations that resulted in performance degradation.
As of Data Grid 7.3, Data Grid sends touch commands to all owners in clustered caches when client read entries that have max-idle expiration values. This ensures that the entries have the same relative access time across the cluster.
Data Grid 8 sends the same touch commands for max-idle expiration across clusters. However there are some technical considerations you should take into account before you start using max-idle. Refer to Configuring Data Grid caches to read more about how expiration works and to review how the touch commands affect performance with clustered caches.
3.4. Persistent cache stores Copiar o linkLink copiado para a área de transferência!
In comparison with Data Grid 7.x, there are some changes to cache store configuration in Data Grid 8.
Persistence SPI
Data Grid 8.1 introduces the NonBlockingStore interface for cache stores. The NonBlockingStore SPI exposes methods that must never block the invoking thread.
Cache stores that connect Data Grid to persistent data sources implement the NonBlockingStore interface.
For custom cache store implementations that use blocking operations, Data Grid provides a BlockingManager utility class to handle those operations.
The introduction of the NonBlockingStore interface deprecates the following interfaces:
-
CacheLoader -
CacheWriter -
AdvancedCacheLoader -
AdvancedCacheWriter
Custom cache stores
Data Grid 8 lets you configure custom cache stores with the store element as in previous versions.
The following changes apply:
-
The
singletonattribute is removed. Useshared=trueinstead. -
The
segmentedattribute is added and defaults totrue.
Segmented cache stores
As of Data Grid 8, cache store configuration defaults to segmented="true" and applies to the following cache store elements:
-
store -
file-store -
string-keyed-jdbc-store -
jpa-store -
remote-store -
rocksdb-store -
soft-index-file-store
As of Data Grid 8.3, file-store element in cache configuration creates a soft index file-based store. For more information see File-based cache stores default to soft index.
Single file cache stores
The relative-to attribute for Single File cache stores is removed in Data Grid 8. If your cache store configuration includes this attribute, Data Grid ignores it and uses only the path attribute to configure store location.
JDBC cache stores
JDBC cache stores must include an xlmns namespace declaration, which was not required in some Data Grid 7.x versions.
<persistence> <string-keyed-jdbc-store xmlns="urn:infinispan:config:store:jdbc:14.0" shared="true"> ... </persistence>
<persistence>
<string-keyed-jdbc-store xmlns="urn:infinispan:config:store:jdbc:14.0" shared="true">
...
</persistence>
JDBC connection factories
Data Grid 7.x JDBC cache stores can use the following ConnectionFactory implementations to obtain a database connection:
-
ManagedConnectionFactory -
SimpleConnectionFactory -
PooledConnectionFactory
Data Grid 8 now use connections factories based on Agroal, which is the same as Red Hat JBoss EAP, to connect to databases. It is no longer possible to use c3p0.properties and hikari.properties files.
As of Data Grid 8.3 JDBC connection factories are part of the org.infinispan.persistence.jdbc.common.configuration package.
Segmentation
JDBC String-Based cache store configuration that enables segmentation, which is now the default, must include the segmentColumnName and segmentColumnType parameters, as in the following programmatic examples:
MySQL Example
PostgreSQL Example
Write-behind
The thread-pool-size attribute for Write-Behind mode is removed in Data Grid 8.
Removed cache stores and loaders
Data Grid 7.3 deprecates the following cache stores and loaders that are no longer available in Data Grid 8:
- Cassandra Cache Store
- REST Cache Store
- LevelDB Cache Store
- CLI Cache Loader
Cache store migrator
Cache stores in previous versions of Data Grid store data in a binary format that is not compatible with Data Grid 8.
Use the StoreMigrator utility to migrate data in persistent cache stores to Data Grid 8.
3.4.1. File-based cache stores default to soft index Copiar o linkLink copiado para a área de transferência!
Including file-store persistence in cache configuration now creates a soft index file-based cache store, SoftIndexFileStore, instead of a single-file cache store, SingleFileStore. In Data Grid 8.2 and earlier, SingleFileStore was the default for file-based cache stores.
If you are migrating or upgrading to Data Grid 8.3, any file-store configuration is automatically converted to a SoftIndexFileStore at server startup. When your configuration is converted to SoftIndexFileStore, it is not possible to revert back to SingleFileStore without modifying the configuration to ensure compatibility with the new store.
3.4.1.1. Declarative configuration Copiar o linkLink copiado para a área de transferência!
Data Grid 8.2 and earlier
Data Grid 8.3 and later
3.4.1.2. Programmatic configuration Copiar o linkLink copiado para a área de transferência!
Data Grid 8.2 and earlier
ConfigurationBuilder b = new ConfigurationBuilder();
b.persistence()
.addStore(SoftIndexFileStoreConfigurationBuilder.class)
.indexLocation("testCache/index");
.dataLocation("testCache/data")
ConfigurationBuilder b = new ConfigurationBuilder();
b.persistence()
.addStore(SoftIndexFileStoreConfigurationBuilder.class)
.indexLocation("testCache/index");
.dataLocation("testCache/data")
Data Grid 8.3 and later
ConfigurationBuilder b = new ConfigurationBuilder();
b.persistence()
.addSoftIndexFileStore()
.indexLocation("testCache/index")
.dataLocation("testCache/data");
ConfigurationBuilder b = new ConfigurationBuilder();
b.persistence()
.addSoftIndexFileStore()
.indexLocation("testCache/index")
.dataLocation("testCache/data");
3.4.1.3. Using single file cache stores with Data Grid 8.3 Copiar o linkLink copiado para a área de transferência!
You can configure SingleFileStore cache stores with Data Grid 8.3 or later but Red Hat does not recommend doing so. You should use SoftIndexFileStore cache stores because they offer better scalability.
Declarative
Programmatic
ConfigurationBuilder b = new ConfigurationBuilder();
b.persistence()
.addSingleFileStore();
ConfigurationBuilder b = new ConfigurationBuilder();
b.persistence()
.addSingleFileStore();
3.5. Data Grid cluster transport Copiar o linkLink copiado para a área de transferência!
Data Grid uses JGroups technology to handle communication between clustered nodes.
JGroups stack configuration elements and attributes have not significantly changed from previous Data Grid versions.
As in previous versions, Data Grid provides preconfigured JGroups stacks that you can use as a starting point for building custom cluster transport configuration optimized for your network requirements. Likewise, Data Grid provides the ability to add JGroups stacks defined in external XML files to your infinispan.xml.
Data Grid 8 has brought usability improvements to make cluster transport configuration easier:
-
Inline stacks let you configure JGroups stacks directly within
infinispan.xmlusing thejgroupselement. -
Declare JGroups schemas within
infinispan.xml. - Preconfigured JGroups stacks for UDP and TCP protocols.
- Inheritance attributes that let you extend JGroups stacks to adjust specific protocols and properties.
3.5.1. Transport security Copiar o linkLink copiado para a área de transferência!
As in previous versions, Data Grid 8 uses the JGroups SYM_ENCRYPT and ASYM_ENCRYPT protocols to encrypt cluster communication.
As of Data Grid you can also use a security realm that includes a keystore and trust store as a TLS server identity to secure cluster transport, for example:
<cache-container> <transport server:security-realm="tls-transport"/> </cache-container>
<cache-container>
<transport server:security-realm="tls-transport"/>
</cache-container>
Node authentication
In Data Grid 7.x, the JGroups SASL protocol enables nodes to authenticate against security realms in both embedded and remote server installations.
As of Data Grid 8, it is not possible to configure node authentication against security realms. Likewise Data Grid 8 does not recommend using the JGroups AUTH protocol for authenticating clustered nodes.
However, with embedded Data Grid installations, JGroups cluster transport includes a SASL configuration as part of the jgroups element. As in previous versions, the SASL configuration relies on JAAS notions, such as CallbackHandlers, to obtain certain information necessary for node authentication.
3.5.2. Retransmission requests Copiar o linkLink copiado para a área de transferência!
Data Grid 8.2 changes the configuration for retransmission requests for the UNICAST3 and NAKACK2 protocols in the default JGroups stacks, as follows:
-
The value of the
xmit_intervalproperty is increased from 100 milliseconds to 200 milliseconds. -
The
max_xmit_req_sizeproperty now sets a maximum of 500 messages per re-transmission request, instead of a maximum of 8500 with UDP or 64000 with TCP.
As part of your migration to Data Grid 8 you should adapt any custom JGroups stack configuration to use these recommended settings.
3.6. Data Grid authorization Copiar o linkLink copiado para a área de transferência!
Data Grid uses role-based access control (RBAC) to restrict access to data and cluster encryption to secure communication between nodes.
Roles and Permissions
Data Grid 8.2 provides a set of default users and permissions that you can use for RBAC, with the following changes:
-
ClusterRoleMapperis the default mechanism that Data Grid uses to associate security principals to authorization roles. -
A new
MONITORpermission allows user access to Data Grid statistics. A new
CREATEpermission that users need to create and delete resources such as caches and counters.NoteCREATEreplaces the___schema_managerand\___script_managerroles that users required to create and remove Protobuf schema and server scripts in Data Grid 8.1 and earlier.When migrating to Data Grid 8.2, you should assign the
deployerrole to users who had the___schema_managerand\___script_managerroles in Data Grid 8.1 or earlier. Use the command line interface (CLI) as follows:[//containers/default]> user roles grant --roles=deployer <user>
[//containers/default]> user roles grant --roles=deployer <user>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
cache manager permissions
| Permission | Function | Description |
|---|---|---|
| CONFIGURATION |
| Defines new cache configurations. |
| LISTEN |
| Registers listeners against a cache manager. |
| LIFECYCLE |
| Stops the cache manager. |
| ALL | - | Includes all cache manager permissions. |
| Permission | Function | Description |
|---|---|---|
| CONFIGURATION |
| Defines new cache configurations. |
| LISTEN |
| Registers listeners against a cache manager. |
| LIFECYCLE |
| Stops the cache manager. |
| CREATE |
| Create and remove container resources such as caches, counters, schemas, and scripts. |
| MONITOR |
|
Allows access to JMX statistics and the |
| ALL | - | Includes all cache manager permissions. |
Cache permissions
| Permission | Function | Description |
|---|---|---|
|
|
| Retrieves entries from a cache. |
| WRITE |
| Writes, replaces, removes, evicts data in a cache. |
| EXEC |
| Allows code execution against a cache. |
| LISTEN |
| Registers listeners against a cache. |
| BULK_READ |
| Executes bulk retrieve operations. |
| BULK_WRITE |
| Executes bulk write operations. |
| LIFECYCLE |
| Starts and stops a cache. |
| ADMIN |
| Allows access to underlying components and internal structures. |
| ALL | - | Includes all cache permissions. |
| ALL_READ | - | Combines the READ and BULK_READ permissions. |
| ALL_WRITE | - | Combines the WRITE and BULK_WRITE permissions. |
| Permission | Function | Description |
|---|---|---|
| READ |
| Retrieves entries from a cache. |
| WRITE |
| Writes, replaces, removes, evicts data in a cache. |
| EXEC |
| Allows code execution against a cache. |
| LISTEN |
| Registers listeners against a cache. |
| BULK_READ |
| Executes bulk retrieve operations. |
| BULK_WRITE |
| Executes bulk write operations. |
| LIFECYCLE |
| Starts and stops a cache. |
| ADMIN |
| Allows access to underlying components and internal structures. |
| MONITOR |
|
Allows access to JMX statistics and the |
| ALL | - | Includes all cache permissions. |
| ALL_READ | - | Combines the READ and BULK_READ permissions. |
| ALL_WRITE | - | Combines the WRITE and BULK_WRITE permissions. |
Cache manager authorization
As of Data Grid 8.2, you can include the authorization element in the cache-container security configuration as follows:
- 1
- Enables security authorization for the cache manager with default roles and permissions.
You can also define global authorization configuration as follows:
Implicit cache authorization
Data Grid 8 improves usability by allowing caches to inherit authorization configuration from the cache-container so you do not need to explicitly configure roles and permissions for each cache.
<local-cache name="secured">
<security>
<authorization/>
</security>
</local-cache>
<local-cache name="secured">
<security>
<authorization/>
</security>
</local-cache>
- 1
- Uses roles and permissions defined in the cache container.
As of Data Grid 8.2, including the
authorizationelement in the configuration uses the default roles and permissions to restrict access to that cache unless you define a set of custom global permissions.