5.2. Resolved Issues

Previously in Red Hat JBoss Data Grid, the server did not contain the deployment scanner which is responsible for handling deployments. As a result, it was not possible to deploy custom user filters, converters and marshallers for enhanced remote listeners by copying jar files with these pieces into the standalone/deployments folder in the server.

This issue is now resolved in JBoss Data Grid 6.4 and the server now contains the deployment scanner and works as expected.

Previously in Red Hat JBoss Data Grid, the default configuration files for JGroups were named jgroups-udp.xml and jgroups-tcp.xml. When a user provided their own configuration file with the same name, it was unexpectedly shadowed with the default one.

This issue is now resolved in JBoss Data Grid 6.4. The default configuration files are now moved to the default-configs directory, renamed to default-jgroups-udp.xml and default-jgroups-tcp.xml. Additionally, if a user chooses the same name for their customized configuration files, a warning is logged.

Previously in Red Hat JBoss Data Grid, the configuration schema for embedded (library) mode did not contain configuration elements for partition handling.

This issue is now resolved in JBoss Data Grid 6.4 and the configurations for partition handling are included in the configuration schema.

Previously in Red Hat JBoss Data Grid, when the backup cache was not defined in the consumer site (with either the same name as the main cache or specified via the <backup-for> option), the customer site would create a new local cache without the RPC manager. This resulted in a NullPointerException being thrown in the consumer site with the following error message also displayed in the producer site:

Unable to pushState to 'XYZ'. org.infinispan.commons.CacheException: Problems invoking command

This issue is now resolved in JBoss Data Grid 6.4 so that if the cache does not exist, it is created with an RPC manager as expected.

Previously in Red Hat JBoss Data Grid, the Map/reduce task missed security actions. As a result, users could not use the Hot Rod size() operation via the map/reduce approach unless they had ADMIN permissions.

This issue is now resolved in JBoss Data Grid 6.4 by adding the required map/reduce security actions. As a result, users with EXEC permissions can now execute map/reduce operations as expected.

Previously in Red Hat JBoss Data Grid, the JPACacheStore was not supported in OSGi/Karaf but the JBoss Data Grid Maven distribution unexpectedly contained a features file for JPACacheStore for deployment in Karaf.

This issue is now resolved in JBoss Data Grid 6.4 and the features file is removed.

Previously in Red Hat JBoss Data Grid, for clusters with more than 16 nodes, node discovery would prevent a new node from joining an existing cluster.

This issue is now resolved in JGroups 3.6.1, which is included in JBoss Data Grid 6.4 so that node discovery allows new nodes to join existing clusters as expected.

Previously in Red Hat JBoss Data Grid, the JGroups subsystem integration with Vault was missing. As a result, sensitive information contained in the JGroups part of configuration files, such as passwords, could not be stored securely using Vault encryption.

This issue is now resolved in JBoss Data Grid 6.4 by adding the JGroups subsystem with Vault. As a result, all passwords, including JGroups passwords, can now be stored securely using Vault.

Previously in Red Hat JBoss Data Grid, the JGroups FD_HOST protocol received an unexpectedly high number of false positive suspects within large clusters.

This issue is now resolved in JBoss Data Grid 6.4 by improving the algorithm used to check the cluster for dead member nodes.

Previously in Red Hat JBoss Data Grid, for a large cluster with many caches, the CacheStatusResponse map on the new coordinator consumed an unexpectedly large amount of memory. As a result, the JVM garbage collection has extra load when selecting a new coordinator for the cluster.

This issue is now resolved in JBoss Data Grid 6.4 by the allowing the caching of various instances in the serializaton context. Reuse results in consistent hashes and repeated cache join information.