Chapter 2. Known Issues

In 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 behavior persists in JBoss Data Grid 6.1.

In rare circumstances, when a node leaves the cluster, instead of going directly to a new cluster view that displays all nodes save the note that has departed, the cluster splits into two partitions, which then merge after a short amount of time. During this time, some nodes do not have access to all the data that previously existed in the cache. After the merge, all nodes regain access to all the data, but changes made during the split may be lost or be visible only to a part of the cluster.

Normally, when the view changes because a node joins or leaves, the cache data is rebalanced on the new cluster members. However, if the number of nodes that leaves the cluster in quick succession equals or is greater than the value of numOwners, keys for the departed nodes are lost. This occurs during a network split as well - regardless of the reasons for the partitions forming, at least one partition will not have all the data (assuming cluster size is greater than numOwners).

While there are multiple partitions, each one can make changes to the data independently, so a remote client will see inconsistencies in the data. When merging, JBoss Data Grid does not attempt to resolve these inconsistencies, so different nodes may hold different values even after the merge.

This behavior persists in JBoss Data Grid 6.1.

The LinkedHashMap implementation in IBM's JDK sometimes behaves erratically when extended (as is done by the eviction strategy code). This wrong behavior is exposed by the JBoss Data Grid Test Suite. It is recommended, if using eviction, to use LIRS eviction strategy, which is not affected by this issue. Only LRU eviction strategy is affected.

This behavior persists in JBoss Data Grid 6.1.

During a node restart, JBoss Data Grid may not start correctly because of duplicate entries in a cache. As a workaround, use a shared cache store instead of local cache stores. Using this workaround, JBoss Data Grid works correctly across restarts and the cache store does not contain duplicate entries.

The root cause of this issue is unknown.

This behavior persists in JBoss Data Grid 6.1.

In JBoss Data Grid, when gracefully stopping a coordinator node, the node itself would log an attempt to install a new clustering view which would fail. This is harmless, since the new coordinator would in fact perform the proper view installation.

This behavior persists in JBoss Data Grid 6.1.

SuspectExceptions are raised when nodes are shutting down, which is normal and expected, since a suspect node is an unresponsive node. As a result, a SuspectException ERROR is written in the logs. There is currently no fix for this issue. The SuspectExceptions will not be logged in a future version of JBoss Data Grid. The SuspectExceptions are harmless and do not affect data integrity.

This behavior persists in JBoss Data Grid 6.1.

Using special characters in directory paths can cause problems when starting JBoss Data Grid server. The JBoss Data Grid server either fails to start or a configuration file for logging capabilities cannot be loaded properly. Special characters include spaces, # (hash sign), ! (exclamation mark), % (percentage sign), $ (dollar sign). This bug causes the JBoss Data Grid server to fail to start properly.Avoiding the use of special characters will stop this problem occuring, allowing JBoss Data Grid server to start properly.

This behavior persists in JBoss Data Grid 6.1.

A race condition in the shutdown sequence causes an attempt to deserialize an incoming response after the externalizer table, which is used for deserialization of messages, has been stopped. Consequently, a SuccessfulResponse not serializable exception is thrown on shutdown. The issue does not cause data corruption and only happens during shutdown, therefore, it does not affect availability.

This behavior persists in JBoss Data Grid 6.1.

Occasionally, while a coordinator node is being shut down, an asynchronous listener thread might attempt to retrieve the state of the cluster and fail with an IllegalStateException.As a result, the IllegalStateException is logged by the coordinator node while it is shutting down.

The IllegalStateException printed by the coordinator node during shutdown can be ignored. The issue does not affect data integrity in any way, and the node will safely shut down.

This behavior persists in JBoss Data Grid 6.1.

The JBoss Operations Network Server plug-in exposes a non-functional "status" operation on a remote site. Consequently, invoking the operation returns an error. As a workaround, use the CLI "site --status ${SITE}" command instead.

As a result of this bug, it is not possible to obtain the status of a remote site using the JBoss Operations Network plug-in however, it is possible when using the CLI.

This behavior persists in JBoss Data Grid 6.1.

The readme file for the Carmart example suggests configuring the cache with eviction and max-entries equal to 4. As a consequence, when opening car's details in the application, the resulting page might be empty as some required cache entries had been already evicted from the cache. This problem occurs only in Remote Client-Server mode.

It is recommended that eviction not be used when configuring the quickstart in Remote Client-Server mode (exclude <eviction/> element). This will allow all cache entries to remain in the cache and details for all cars to be available to the application.

This behavior persists in JBoss Data Grid 6.1.