5.2. Resolved Issues

Nested indexed fields would sometimes be reported as unindexed even if the metadata says otherwise. This could cause a query to be run fully or partially unindexed, resulting in performance issues.

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

ContinuousQueryListener.resultJoining notifications generated by modify operations contain the old value not the new one. This issue only affected queries without projections.

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

When a topology change occurs, such as a node joining the cluster, the connecting client receives HotRodClientException and InvalidResponseExceptions whenever it would execute a get operation.

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

A NullPointerException could be thrown during rebalancing. This exception was caused by FutureCollator.futures.get() querying the map before FutureCollator.futures.put() completed.

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

When using the Hot Rod Java client with multiple backpus it was possible to have the Cache.remove() method fail, without attempting a retry, if one of the backups is no longer available.

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

Rolling upgrades failed if the key set was larger than 2 GB of memory. The process failed when calling recordKnownGlobalKeyset because the keys could not be dumped into a single byte array in the source cluster.

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

When performing a rolling upgrade a ClassCastException was thrown on each getWithMetadata() for every key.

This issue was related in the EntryWrapping logic when reading data from a remote store, and is resolved as of Red Hat JBoss Data Grid 6.6.1.

Previously, the Hot Rod client had the SSLContext set with a hardcoded TLS protocol. This prevented java 7 clients from using TLSv1.2, since it was not enabled by default.

This has been addressed in JBoss Data Grid 6.6.1 by allowing clients to specify a SSL protocol via the infinispan.client.hotrod.ssl_protocol property. To use the TLSv1.2 protocol the following should be defined:

infinispan.client.hotrod.ssl_protocol=TLSv1.2

infinispan.client.hotrod.ssl_protocol=TLSv1.2

If no protocol is defined JBoss Data Grid defaults to using TLS.

A HashSet was created from the AdvancedAsyncCacheLoader$process operation, which was then accessed by a series of tasks running in parallel, resulting in the possibility of infinite loops.

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

The evictions attribute of Statistics and ClusterCacheStats components of the Cache MBean returned zero even though some eviction operations have been successfully performed. This issue only affected statistics, not the actual eviction process.

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

If a timeout occurred when using the clear command the lock it was holding was never released, resulting in a deadlock as the Hot Rod client retried the command on another node.

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

When starting a series of JBoss Data Grid nodes in parallel, and having each node register a queried class to the __cluster_registry_cache__, lock timeout errors were printed.

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

When a Hot Rod operation resulted in an error, RetryOnFailureOperation would invalidate the connection twice. Initially in a catch block, and a second time in a finally block. This behavior resulted in the GenericKeyedObjectPool counts to become unreliable.

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

When executing remote transactions as the server is shutting down, the client could become blocked or receive TimeoutException errors.

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

Previously it was possible for the FILE_PING JGroups discovery method to include a file separator, such as / or \.

This issue is resolved as of Red Hat JBoss Data Grid 6.6.1, as these characters are now replaced with -.

When using the Hot Rod Java client the time to recover takes twice as long if the coordinator is killed. This was due to VERIFY_SUSPECT executing twice.

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

During shutdown, the TransactionTable unregisters itself as a view change listener, but it can still receive view change notifications after it stopped the executor service. When this happens, it causes a RejectedExecutionException that is eventually logged by JGroups.

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

When configuring JBoss Data Virtualization to connect to a JBoss Data Grid remote cache using the Hot Rod EAP client modules, ProtoSchemaBuilder is called, resulting in a NotFoundException error being thrown.

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

If a client used the JCache API together with the remote-java-client library a getCache(cacheName) would return NULL, even if the cache is configured within the server. This was caused by the JCache API not examining remote caches.

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

If an application used the JCache API together with the infinispan-jcache-remote library then the CacheManager was created with default properties, as no property files were passed into the constructor.

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

A JBoss Data Grid 6.x node communicating to a JBoss Data Grid 7 server was unable to authenticate using the SASL_EXTERNAL method, as this is a new feature in JBoss Data Grid 7.

This issue is resolved for Red Hat JBoss Data Grid 6.6.1 clients. These clients may now use the server's SSL certificate CN chain to authenticate the user.

Some properties, such as SSL, FILE_STORE, and TRUST_STORE, were only allowed to be defined programmatically, and could not be placed in the hotrod-client.properties file.

This issue is resolved for Red Hat JBoss Data Grid 6.6.1 clients, and these properties may be defined either programmatically or declaratively.

It was found that JGroups did not require necessary headers for encrypt and auth protocols from new nodes joining the cluster. An attacker could use this flaw to bypass security restrictions, and use this vulnerability to send and receive messages within the cluster, leading to information disclosure, message spoofing, or further possible attacks.

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