6.1.0 Release Notes

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.

If a cache entry is in the process of being written to the underlying store (somewhere in the async queue) and the entry is being loaded from the store at the same time, the entry was already removed from the container and if not yet written on the store it might not be found. Consequently, cache entries might not be found in a short time window between the moment they are evicted and the moment they are written to the underlying cache store.

This was to have been fixed with a new write-behind cache store implementation. However, the actual fix has not yet been thoroughly tested, and as such this issue is still considered unresolved.

A NullPointerException is thrown when reading objects back from file to a cache. As a result, the Asynchronous FileCacheStore does not work correctly in Tomcat container. There is no workaround for this issue at this stage, and the root cause is unknown.

A Maven shade plug-in, which handles creating a resulting jar file for hotrod-endpoint quickstart, is not able to process required dependencies and fails. As a result, the hotrod-endpoint example cannot be built. As a workaround, configure maven-assembly-plugin so that it creates the resulting jar file with all required dependencies. The hotrod-endpoint example can now be built and started.

While JBoss Data Grid 6.1 has introduced support for rolling upgrades via Hot Rod, JBoss Data Grid 6.0 is lacking functionality which would enable a rolling upgrade from that version to a newer version. It is therefore not possible to perform a rolling upgrade from JBoss Data Grid 6.0 to JBoss Data Grid 6.1.

The JBoss Data Grid 6.0 instance should be configured with a persistent cache store so that all states are persisted to it. After shutting down the JBoss Data Grid 6.0 instance, a JBoss Data Grid 6.1 instance, configured to retrieve the persistent state from the same cache store, can be started in its place. An upgrade from JBoss Data Grid 6.0 to JBoss Data Grid 6.1 is not a seamless operation but requires a complete shutdown of the system in order to be performed.

An issue in the implementation of the storage of entries written via the REST protocol produces wrong results when the entries are compared. As a result, the replace operation invoked via the REST protocol will fail and the cache will still contain the old entry. There is no workaround available for this issue.

The Infinispan subsystem of JBoss Data Grid Server only exposes metrics and statistics to the JBoss Operations Network plug-in. It does not yet expose the operations which are possible on a cache's components. Therefore, it is not possible to invoke operations on cache containers and caches via the JBoss Operations Network JBoss Data Grid Server plug-in.

There is currently no way to invoke the missing operations via the JBoss Operations Network JBoss Data Grid Server plug-in. However some of these operations can be invoked by connecting to the JBoss Data Grid server via JMX or via the JBoss Data Grid CLI.

An issue in the JBoss Operations Network JBoss Data Grid library plug-in causes all operations invoked on cache managers/caches to return a NullPointerException. The operation is correctly executed, however an error is always reported by the plug-in.

Occasionally during a conditional replace operation performed via the REST interface, a NullPointerException is thrown. This causes a NullPointerException ERROR to be reported during the replace operation. The actual outcome of the replace operation in this case is undetermined, and there is currently no workaround for this issue.