Chapter 5. Known Issues

In Red Hat JBoss Data Grid's library mode, JDBC cache stores can be configured to use a JTA-aware datasource. However, operations performed on a cache backed by such a store during a JTA transaction will be persisted to the store outside of the transaction's scope. This issue is not applicable to JBoss Data Grid's Remote Client-Server mode because all cache operations are non-transactional.

SuspectExceptions are routinely raised when nodes are shutting down because they are unresponsive as they shut down. As a result, a SuspectException error is added to the logs. The SuspectExceptions do not affect data integrity.

No workaround is currently available for this issue.

When special characters are used in the directory path, the JBoss Data Grid server either fails to start or a configuration file used for logging cannot be loaded properly. Special characters that cause problems include spaces, # (hash sign), ! (exclamation mark), % (percentage sign), and $ (dollar sign).

The only workaround for this issue is to avoid using special characters in the directory path.

When a site is unreachable, JGroups's RELAY2 logs an error for each dropped message. Infinispan has configurable fail policies (ignore/warn/abort), but the log is filled with errors despite the ignore policy.

Transactional caches are configured with optimistic locking by default. Concurrent replace() calls might return true under contention and transactions might commit even if they are not supposed to.

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

As a workaround, enable REPEATABLE_READ isolation level and write skew check. This will result in concurrent replace operations working as expected.

Currently, it is not possible to create a remote cache store child resource for a cache using the JBoss Data Grid Remote Client-Server plug-in for JBoss Operation Network. The operation subsequently fails and the JBoss Operations Network Agent records the failure in its log file. As a result, a remote cache store cannot be configured using the JBoss Operations Network user interface.

As a workaround for this issue, modify the JBoss Data Grid server configuration file to manually configure the remote cache store.

JPA Cache Store does not work with Oracle12c and Postgres Plus 9 as Hibernate, an internal dependency of JPA Cache Store, is not able to determine which dialect to use for communication with the database.

To work around this issue, you have to specify Hibernate dialect directly in our persistence.xml. You can do it by adding following element in our persistence.xml: , where ${hibernate.dialect} should be set up to org.hibernate.dialect.Oracle10gDialect or org.hibernate.dialect.PostgresPlusDialect for Oracle12c or Postgres Plus 9, respectively.

CLI upgrade command fails to migrate data from the old cluster to the new cluster if the data being migrated were stored in the old cluster via CLI (e.g. by issuing command put --codec=hotrod key1 val1). This issue does not occur if data were store via Hot Rod or REST clients directly.

When using put/remove operations via Hot Rod, some objects might not be indexed if the system is under heavy load. These object will not be returned by Remote Query or returned based on their previous state. This also affects embedded querying when the cache is NOT transactional.

This bug may also cause loss of update and delete operations, so while it is true that subsequent queries might miss results of newly inserted objects, they might also contain results which are not supposed to be returned. The problem on missed delete operations only affects usage of projection, as when the user asks to return the object from the grid we remove the missing ones from the results.

The workaround is to mark the cache transactional, regardless of the cache being accessed over Hot Rod (note that then every single operation is enclosed in a transaction) or locally as an embedded cache.

When a cache using LevelDB cache store is stopped (for example, as a consequence of stopping the cache manager), the LevelDB native implementation can cause segmentation fault in the JVM process. This results in crashing the whole process.