6.5.1 Release Notes

JCache annotations provides a way to define a custom CacheResolverFactory, used to produce CacheResolver; this class's purpose is to decide which cache is used for storing results of annotated methods; however, the support for specifying a CacheResolver is not provided yet.

Define a CDI ManagedCacheResolver which will be used instead.

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

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

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

When creating a new cache (which is not defined in server configuration file) in HotRod implementation of JSR-107, the cache is created as local only in one of the servers. This behavior requires class org.jboss.as.controller.client.ModelControllerClient to be present on the classpath.

As a workaround use a clustered cache defined in the server configuration file. This still requires cacheManager.createCache(cacheName, configuration) to be invoked before accessing the cache for the first time.

A JPA Cache Store deployed to WebLogic servers throws a NullPointerException after the following error message:

This is a known issue in JBoss Data Grid 6.5.1, and no workaround exists at this time.

The getCache operation on RemoteCacheManager may ignore the forceReturnValue flag in the manager.getCache("foo", true) call. This behavior results in a cache with the forceReturnValue flag set to false instead of the expected value.

This is a known issue in JBoss Data Grid 6.5.1, and no workaround exists at this time.

When using a near cache in LAZY mode there was a possibility that a read operation following a write operation on the same key within the same thread would return outdated data. For example, the below calls from the same thread could result in v1 being returned:

This issue is resolved as of Red Hat JBoss Data Grid 6.5.1.

When using the HotRod client to update the lifespan of an expirable entry so that it will be immortal (i.e. performing put with lifespan set to -1), the entry was unexpectedly removed from the cache.

This issue is resolved as of Red Hat JBoss Data Grid 6.5.1.

AsyncCacheWriter could drop updates if it was unable to write modificationQueueSize entries within the shutdownTimeout, as older changes overwrote newer ones in the back-end store. This issue was primarily caused by a large queue size or a slow back-end store with a relatively small AsyncStore shutdownTimeout (25 seconds by default).

Now AsyncStore will write everything to the backing store before shutting down, and the shutdownTimeout has been removed.

This issue is resolved as of Red Hat JBoss Data Grid 6.5.1.

A race condition existed that allowed AsyncCacheLoader.load() / State.get() to return stale data. As State.get() scans the states of AsyncCacheWriter from head to tail, while the AsyncStoreCoordinator may move conflicting entries from the current state to the head state. If State.get() / AsyncCacheLoader.load() is preempted after checking the head state then it may not see modifications moved by the coordinator thread and load stale data instead.

This issue is resolved as of Red Hat JBoss Data Grid 6.5.1; the AsyncStoreCoordinator was redesigned so that conflicting keys are collected in a separate list which is processed after the AsyncStoreProcessors complete.

When size() is performed using the HotRod client, a MapReduce task is invoked internally to determine the total number of entries present in the cache. Previously this operation did not require any permissions; however, a check has been added to ensure the role invoking size() has the BULK_READ permission.

This issue is resolved as of Red Hat JBoss Data Grid 6.5.1.

The only isolation level supported by server configuration in the <locking> element of cache configuration was READ_COMMITED. Due to this, the server incorrectly printed 'Ignoring XML attribute isolation, please remove from configuration file' log message, even if isolation attribute was not present in the <locking> element.

This issue is resolved as of Red Hat JBoss Data Grid 6.5.1 as the server currently supports specifying other isolation levels, resulting in the log message no longer being displayed.

When a clustered listener is registered and it throws an exception which is not caught, the listener is put in an inconsistent state. This might result in further exceptions when processing the next events, even if those events should generate no error or exception.

This issue is resolved as of Red Hat JBoss Data Grid 6.5.1.

The Hot Rod decoder was not reporting all errors produced, resulting in a combination of errors not being logged and byte buffers being leaked as these errors accumulated. As these buffers grew they could potentially cause OutOfMemory errors.

This issue is resolved as of Red Hat JBoss Data Grid 6.5.1, as the Hot Rod decoder extends a different Netty decoder that handles all potential failures.

The C++ HotRod client was occasionally logging the following exception when there were many concurrent Put and Get operations:

This issue was caused by the message id counter not being thread safe.

This issue is resolved as of Red Hat JBoss Data Grid 6.5.1.

The server configuration did not allow users to specify write skew check option. This behavior could lead to inconsistencies on failure scenarios when using conditional operations with optimistic locking caches.

This issue is resolved as of Red Hat JBoss Data Grid 6.5.1, where write skew check is automatically enabled when using a combination of optimistic locking, synchronous cache mode, and REPEATABLE_READ isolation level.

The HotRod C++ client's failover was failing sporadically under high load. This was caused by the Transport object throwing a TransportException during an operation, resulting in a ConnectionPool::invalidateObject which removed the Transport from the busy queue, destroyed the Transport, and then added a new Transport to the idle queue. When the new Transport is created, it tries to connect to the server socket which fails. This prevents retry attempts and client failover from happening.

This issue is resolved as of Red Hat JBoss Data Grid 6.5.1.

When compatibility mode was enabled in distributed mode and the number of key owners was less than the number of nodes in the cluster, the getAll operation on the HotRod client performed a local getAll, which sometimes resulted in not returning all entries.

This issue is resolved as of Red Hat JBoss Data Grid 6.5.1.

The call to putIfAbsentAsync on a remote HotRod client and using withFlags(Flag.FORCE_RETURN_VALUE) did not work as expected. The previous value was not returned as expected unless the flag was also configured in HotRod client properties file.

This issue is resolved as of Red Hat JBoss Data Grid 6.5.1.

While using a deployed Custom Cache Store for a particular cache, there was a potential race condition in the JBoss Data Grid server. It was possible that the cache start-up would occur before the Custom Cache Store library registration was successfully finished, resulting in the cache being unable to find the requested resources during the start-up process and failing to start.

This issue is resolved as of Red Hat JBoss Data Grid 6.5.1.