Chapter 5. Known and Resolved Issues

In Red Hat JBoss Data Grid, using the two phase commit with the ASYNC backup strategy results in one phase commit unexpectedly being used instead.

This is a known issue in JBoss Data Grid 6.4 and no workaround is currently available for this issue.

In Red Hat JBoss Data Grid, the distribution of entries in the cluster changes when a node joins, leaves or crashes during a brain split. During this brief period, a read on the previous node owner can return stale data. When the rebalance process is completed, further reads return up-to-date data.

This is a known issue in JBoss Data Grid 6.4 and no workaround is currently available for this issue.

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

In Red Hat JBoss Data Grid, 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.

This is a known issue in JBoss Data Grid 6.4 and no workaround is currently available for this issue.

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

In Red Hat JBoss Data Grid, the server principal is always constructed as jgroups/server_name and is not loaded from the Kerberos login module. Using a different principal results in an authentication failure.

This is a known issue in JBoss Data Grid 6.4 and the workaround for this issue is to use jgroups/server_name as the server principal.

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.4 and a workaround is to use the PLAIN authentication over end-to-end SSL encryption.

In Red Hat JBoss Data Grid, 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).

This is a known issue in JBoss Data Grid 6.4. A workaround for this issue is to avoid using special characters in the directory path.

In Red Hat JBoss Data Grid, 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.

This is a known issue in JBoss Data Grid 6.4. As a workaround for around this issue, specify the Hibernate dialect directly by adding the following element in the persistence.xml file:

<property name="hibernate.dialect" value="${hibernate.dialect}" />

<property name="hibernate.dialect" value="${hibernate.dialect}" />

Set ${hibernate.dialect} to org.hibernate.dialect.Oracle10gDialect or org.hibernate.dialect.PostgresPlusDialect for Oracle12c or Postgres Plus 9 respectively.

In Red Hat JBoss Data Grid, the CLI upgrade command fails to migrate data from the old cluster to the new cluster if the data being migrated was stored in the old cluster via CLI with REST encoding (e.g by issuing a command such as put --codec=rest key1 val1). This issue does not occur if data is stored via REST clients directly.

This is a known issue in JBoss Data Grid 6.4 and no workaround is currently available for this issue.

In Red Hat JBoss Data Grid, when a cache contains a large number of entries, the clear() operation can take an unexpectedly long time and possibly result in communication timeouts. In this case, the exception is reported to the Hot Rod client.

This is a known issue in JBoss Data Grid 6.4 and no workaround is currently available for this issue.

In Red Hat JBoss Data Grid, for a cache store where sharing is set to false, the fetchInMemory and fetchPersistence parameters must also be set to true or different nodes may contain different copies of the same data.

For a cache store where the shared parameter is set to true, set fetchPersistence must be set to false because the persistence is shared and enabling it results in unnecessary state transfers.

However, the fetchInMemory parameter can be set to either true or false. Setting this to true loads the in-memory state via the network and resulted in a faster start up. Setting the value to false loads the data from persistence without transferring the data remotely from other nodes.

This is a known issue in JBoss Data Grid 6.4 and the only workaround for this issue is to follow the stated guidelines above and to ensure that each node in the cluster uses the same configuration to prevent unexpected results based on the start up order.

In Red Hat JBoss Data Grid, SuspectExceptions are routinely raised when nodes shut 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.

This is a known issue in JBoss Data Grid 6.4 and no workaround is currently available for this issue.

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.

This is a known issue in JBoss Data Grid 6.4 and no workaround is currently available for this issue.

In Red Hat JBoss Data Grid, it is possible to change rebalancing settings using the JBoss Operations Network UI when navigating to the JBoss Data Grid Server/Cache Container/Cache/Configuration (current)/Distributed Cache Attributes/Rebalancing.

This operation is currently misrepresented as a cache-level operation when the changed rebalancing settings automatically apply for all the parent cache manager's caches and for all nodes in a particular cluster.

This is a known issue in JBoss Data Grid 6.4 and no workaround is currently available for this issue.

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.4 and no workaround is currently available for this issue.