Chapter 5. Resolved Issues

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.