The LinkedHashMap implementation in IBM's JDK behaves erratically when extended (as is done by the eviction strategy code). This incorrect behavior is exposed by the Red Hat 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.

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 Red Hat JBoss Data Grid. The SuspectExceptions do not affect data integrity.

Using special characters in directory paths can cause problems when starting Red Hat 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 occurring, allowing JBoss Data Grid server to start properly.

A race condition in the Red Hat JBoss Data Grid 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 and does not affect availability.

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

The queue-flush-interval and queue-size attributes of a replicated cache are ignored when data is stored remotely from Memcached client. This is caused by the "distribution-based replication" algorithm in JBoss Data Grid: a key's primary owner might not be the local node, so a synchronous put operation is sent to the key owner, thus overriding the async queue.

Consequently, data is replicated immediately and the queue-flush-interval and queue-size attributes are not respected.

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

When a Map/Reduce task is executed against a cache with many small values, the task may experience TimeoutExceptions while trying to write the intermediate results to the cache.As a result, when these exceptions occur, the task fails.

There are several things the user can do to try and alleviate this issue:

In distributed cache mode with L1 enabled and onRehash=true, when an entry is overwritten during state transfer, the overwrite may be ignored. This node will then report an outdated value of the entry, and after L1 timeout this entry will be completely removed.

As a workaround, use L1 with onRehash=false.

Sending a message through JGroups may fail under some race conditions with ArrayOutOfBoundException. The reliability mechanism will try to resend this message again, but all these subsequent attempts will fail with NullPointerException.

Therefore, the message will be never received on the receiver node and will be held in unacknowledged messages buffer on the sender node. If this message is ordered within JGroups, no more ordered messages from this node will be delivered on the receiver node. Some following messages may be buffered as well, eventually leading to OutOfMemoryException.

It is recommended to use UNICAST3 as this dramatically reduces the chance of this bug to happen (it was observed with UNICAST2).

When REPEATABLE_READ isolation mode is enabled, reading values from AtomicMap and FineGrainedAtomicMap is not consistent within the same transaction. If another thread changes the value during the transaction, the new value is reflected immediately in the current thread while the thread should still see the original value.

The writeSkewCheck flag does not work correctly for AtomicMap. When JBoss Data Grid runs in REPEATABLE_READ isolation mode for transactions, the writeSkewCheck flag is enabled, and two concurrent transactions read/write data from the same AtomicMap. The WriteSkewException exception is never thrown when committing either of the transactions.

Consequently, the data stored in the AtomicMap might be changed by another transaction, and current transaction will not register this change during commit.

By default, the C++ Hot Rod client resolves server host names using IPv4 addresses. If a server is listening on an IPv6 address, the client will not be able to connect to it.

Either specify the server using its IP instead of the name or set the HOTROD_IPSTACK environment variable to IPV4 or IPV6 to force resolution using the preferred stack. The client will connect to the specified server.

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.

Red Hat JBoss Data Grid server is not able to parse XML configuration for a custom cache loader if the configuration contains child elements, such as custom properties, inside <loader> element. As a result, JBoss Data Grid server fails to start.

The support for child elements of <loader> element has been implemented. Result: Custom cache loader inside JDG server allows for nested configuration tags and can successfully start with such a configuration.

When data is being migrated via CLI from a node with old version of JBoss Data Grid to a node with new version, an error occurs during synchronization. This happens when the upgrade command is called on the new node with parameter --synchronize=hotrod. This results in data not properly migrating from the old node to the new one.

When an entry is placed in a clustered cache with a ClusterCacheLoader defined, the client gets NullPointerException. As a result, it is not possible to use ClusterCacheLoader reliably.

There are certain types of remote-side exceptions that the Java Hot Rod client will not recover from by retrying, even though it should be possible. This also happens when the org.infinispan.remoting.RemoteException is thrown in the server. The HotRodClientException is thrown on the client side, the operation does not retry and the issue needs to be handled by the user code.

The rolling upgrade procedure for the REST client migrates data from a previous version of JBoss Data Grid server ("source") to a new version ("target"). The rest-store configuration element is required for this procedure to succeed. However, it is not possible to successfully start the "target" node with rest-store element defined. The server fails to start with java.lang.ClassNotFoundException: org.apache.commons.codec.EncoderException

As a result, it is not possible to perform rolling upgrades with REST client from JBoss Data Grid 6.1.0.GA to JBoss Data Grid 6.2.0.Beta.

In Remote Client-Server mode, when a remote-store is defined with a read-only attribute set to true, this attribute is ignored. As a result, data may be stored in the remote store despite it being defined as read-only.

JBoss Data Grid fails to instantiate GlobalComponentRegistry on IBM JDK 1.6. This process fails with IllegalArgumentException: Argument Type Mismatch. As a result, JBoss Data Grid does not work correctly on IBM JDK 1.6. Instead, use IBM JDK version 1.7 instead of version 1.6. JBoss Data Grid works correctly on IBM JDK 1.7.

In a cluster with L1 enabled, during rebalancing after a node joins or leaves the cluster, an entry may be lost on a node.

During the cluster rebalance process, after a node joins or leaves the cluster, a read operation may retrieve data that has already been overwritten. The behavior was observed in transactional mode but may not be limited to it.

With L1 enabled, a node may cache an already overwritten entry. Further reads on this node will return out-of-date value.

In a non-transactional cache, conditional operations executed during cluster rebalance after a node joins or leaves may not test and set the value atomically - two competing commands may both override the value.

With L1 enabled, after a cluster rebalance following a node joining or leaving, L1 may stay outdated on a node - reads from this node will not reflect further writes to the entry until the entry times out from the L1.

The rolling upgrade process for Hot Rod fails with IOException during call of recordKnownGlobalKeyset operation. Consequently, it is not possible to successfully go through rolling upgrade process for Hot Rod client from version JBoss Data Grid 6.1.0.GA to JBoss Data Grid 6.2.0.Beta.

The C++ Hot Rod client has a hard-coded level of intelligence (level 1). As a result, the client has only basic intelligence, which means it is not topology aware. Thus, when the client connects to a cluster, and servers join or leave the cluster, the client will not be aware of it.

As a workaround, when new nodes join the cluster or leave it while the C++ client is connected, ensure all clients are restarted to get the new view of the cluster. Another option is to make sure no servers leave or join the cluster during the session.