Chapter 5. Known and Resolved Issues

When using an async cache any cache.clear() calls do not remove data in the table. cache.getKey() returns null as expected; however, the table entries are still present.

As a workaround for this issue use a synchronous cache store. This issue is expected to be addressed in JDG 7.

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.

Define a CDI ManagedCacheResolver which will be used instead.

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 JBoss Data Grid 6.5 and no workaround is currently available for this issue.

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 JBoss Data Grid 6.5 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 JBoss Data Grid 6.5. As a workaround, enable write skew check and the REPEATABLE_READ isolation level. This results in concurrent replace operations working as expected.

In the case when Custom Cache Store .jar file deployment into JDG server is happening via JBoss Operation Network UI (JDG server -> Create Child -> Deployment), the Deployment is registered by the JDG server too late. I.e. after the start of caches. Consequently, caches report error messages if they are configured to use Custom Cache Store implementation.

As a workaround, either copy Custom Cache Store .jar file into $JDG_HOME/standalone/deployments folder or use the deploy command in server CLI.

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.

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

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

While using a deployed Custom Cache Store for a particular cache, there is a potential race condition in the JBoss Data Grid server. It is possible that the cache start-up will occur before the Custom Cache Store library registration is successfully finished, resulting in the cache being unable to find the requested resources during the start-up process and failing to start.

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