When creating a new cache (which is not defined in server configuration file) in HotRod implementation of JSR-107, the cache is created as local only in one of the servers. This behavior requires class org.jboss.as.controller.client.ModelControllerClient to be present on the classpath.

As a workaround use a clustered cache defined in the server configuration file. This still requires cacheManager.createCache(cacheName, configuration) to be invoked before accessing the cache for the first time.

JCache annotations provides a way to define a custom CacheResolverFactory, used to produce CacheResolver; this class's purpose is to decide which cache is used for storing results of annotated methods; however, the support for specifying a CacheResolver is not provided yet.

As a workaround, define a CDI ManagedCacheResolver which will be used instead.

A JPA Cache Store deployed to WebLogic servers throws a NullPointerException after the following error message:

Entity manager factory name (org.infinispan.persistence.jpa) is already registered

This is a known issue in Red Hat JBoss Data Grid 6.6.0, and no workaround exists at this time.

In Red Hat JBoss Data Grid, when a node restarts, it does not automatically purge entries from its local cache store. As a result, the Administrator starting the node must change the node configuration manually to set the cache store to be purged when the node is starting. If the configuration is not changed, the cache may be inconsistent (removed entries can appear to be present).

This is a known issue in Red Hat JBoss Data Grid 6.6.0, and no workaround exists at this time.

In Red Hat JBoss Data Grid, the server does not support pass-through MD5 authentication against LDAP. As a result, the Hot Rod client is unable to authenticate to the JBoss Data Grid server via MD5 is the authentication is backed by the LDAP server.

This is a known issue in Red Hat JBoss Data Grid 6.6.0 and a workaround is to use the PLAIN authentication over end-to-end SSL encryption.

In Red Hat JBoss Data Grid, transactional caches are configured with optimistic locking by default. Concurrent replace() calls can return true under contention and transactions might unexpectedly commit.

Two concurrent commands, replace(key, A, B) and replace(key, A, C) may both overwrite the entry. The command which is finalized later wins, overwriting an unexpected value with new value.

This is a known issue in Red Hat JBoss Data Grid 6.6.0. As a workaround, enable write skew check and the REPEATABLE_READ isolation level. This results in concurrent replace operations working as expected.

Rolling upgrades fail if the key set is larger than 2 GB of memory. The process fails when calling recordKnownGlobalKeyset because the keys cannot be dumped into a single byte array in the source cluster.

This is a known issue in Red Hat JBoss Data Grid 6.6.0, and no workaround exists at this time.

The evictions attribute of Statistics and ClusterCacheStats components of the Cache MBean return zero even though some eviction operations have been successfully performed. This issue only affects statistics, not the actual eviction process.

This is a known issue in Red Hat JBoss Data Grid 6.6.0, and no workaround exists at this time.

When authorization is configured for a cache, then any access to the cache via REST endpoint results in a security exception. A user is not able to access the cache since the security Subject representing the user is not properly defined, and the user cannot be authorized to access the cache.

This is a known issue in Red Hat JBoss Data Grid 6.6.0, and no workaround exists at this time.

In Red Hat JBoss Data Grid, when both infinispan-remote and infinispan-embedded dependencies are on the classpath, the Infinispan CDI extension does not work as expected. This is due to bundling the Infinispan CDI extension in both jar files. As a result, CDI fails with ambiguous dependencies exception.

This is resolved as of Red Hat JBoss Data Grid 6.6.0. The content of infinispan-embedded and infinispan-remote were restructured so that only one of the jar files is needed for any use case. There is no need to use them together anymore.

The server configuration did not allow users to specify write skew check option. This behavior could lead to inconsistencies on failure scenarios when using conditional operations with optimistic locking caches.

This issue is resolved as of Red Hat JBoss Data Grid 6.6.0, where write skew check is automatically enabled when using a combination of optimistic locking, synchronous cache mode, and REPEATABLE_READ isolation level.

The metrics for local caches were not properly registered within the server. As a result, local cache resources were not available in the JON UI. This issue was only related to local caches and did not affect clustered caches.

This issue is resolved as of Red Hat JBoss Data Grid 6.6.0.

In Red Hat JBoss Data Grid the custom audit logger option was ignored in server mode, and the default audit logger was not turned on.

This issue is resolved as of Red Hat JBoss Data Grid 6.6.0. Users can now set up their own audit logger, and if no audit logger is provided, then the default audit logger is used.

When using a cache configured with expiration in remote JCache implementation, expiration events were not handled in clustered environment on cache c1, if the insertion of an entry was performed by cache c2. As a consequence, cache entry listener registered on cache c1 was not notified of the expiration event.

The issue is resolved as of Red Hat JBoss Data Grid 6.6.0, and cache entry listeners receive expiration events correctly in clustered environment.

When using the HotRod client in JBoss Data Grid's Remote Client-Server mode, there was a possibility that an outdated view was used when the cluster healed from network partition. This could lead to data inconsistencies when performing operations by clients that received different views.

The issue is resolved as of Red Hat JBoss Data Grid 6.6.0. The HotRod client correctly receives an updated view after the partition is healed.

In Red Hat JBoss Data Grid, when roles based authentication was enabled, the HotRod client did not fail over; instead, it logged the exception when the JDG server to which the client was connected and went offline.

This issue is resolved as of Red Hat JBoss Data Grid 6.6.0. If the JDG server shuts down, then the HotRod client will fail over to another JDG server in the cluster silently, with no exception logged and the HotRod client will continue to work properly.

Expiration settings of a cache were ignored in JBoss Data Grid server if putIfAbsent operation was invoked via HotRod client. This could lead to wrong assumptions about presence of an entry in the cache, which never expired.

The issue is resolved as of Red Hat JBoss Data Grid 6.6.0. The entry correctly expires after predefined time period.

In Red Hat JBoss Data Grid, when node authentication was enabled and a JDG node left the cluster it was not able to rejoin the cluster.

This issue is resolved as of Red Hat JBoss Data Grid 6.6.0. When node authentication is turned on, then the JDG node can rejoin the cluster without any issue.

When size() is performed using the HotRod client, a MapReduce task is invoked internally to determine the total number of entries present in the cache. Previously this operation did not require any permissions; however, a check has been added to ensure the role invoking size() has the BULK_READ permission.

This issue is resolved as of Red Hat JBoss Data Grid 6.6.0.

There was a possibility of a transactional cache erroneously throwing ClassCastException when an entry was obtained while located on a remote node.

This issue is resolved as of Red Hat JBoss Data Grid 6.6.0.