This section lists the new features, enhancements, fixed issues and, removed or deprecated features for 3.8 release.
The following are the new features introduced with 3.8 release.
Hazelcast IMDG Enterprise Features
- Rolling Member Upgrades for Minor Releases: You can upgrade your Hazelcast members to the next minor release without service interruption. Please refer to the Rolling Member Upgrades chapter.
- Restore Hot Restart Data in a Different Cluster: You will be able to restore Hot Restart data on a completely new cluster with different IP addresses or on a cluster of machines formed by existing and new IP addresses. Since this is a removal of a restriction or limitation, nothing will change for current Hot Restart Store users. Please refer to the Moving/Copying Hot Restart Data section.
Hazelcast IMDG Open Source Features
- Continuous Query Cache: With this release, the previously Enterprise feature Continuous Query Cache becomes open source. Please refer to the Continuous Query Cache section.
- Cardinality Estimator: Cardinality Estimator data structure is implemented on top of Hazelcast to estimate cardinality. Please refer to the Cardinality Estimator Service section.
Scheduled Executor Service: Distributed implementation of Java's
ScheduledExecutorServiceAPI. Please refer to the Scheduled Executor Service section.
- User Code Deployment: Load your new classes to Hazelcast IMDG members dynamically without restarting all of them.
The following are the enhancements introduced with 3.8 release.
- Fast Aggregations for Queries: Please refer to Fast Aggregations section.
- Projections for Queries: Please refer to Projections section.
- Eventually Consistent Near Cache: With this improvement, possible losses of invalidation events are detected and stale reads are prevented. Please refer to the Near Cache Eventual Consistency section.
- Cluster Split-Brain Protection for Queue and Lock: Split-brain protection is now available for the queue and lock data structures. Please refer to the sections Lock Split-Brain Protection and Queue Split-Brain Protection.
- Unified Near Cache Implementation: Different near cache implementations for JCache, map, client side and member side are unified. You can refer to the Near Cache section.
- High Performance Near Cache: A near cache preloader is introduced to preserve the information about which keys are used in a populated near cache. You can refer to the Near Cache Preloader section.
removeAll(predicate)for Map: You can remove all map entries that match your predicate. You can refer to the Removing Bulk Map Entries with Predicates section.
- Ringbuffer with Persistent Datastore: Implemented for the Ringbuffer which is similar to the existing queue store mechanism. Please refer to Ringbuffer with Persistent Datastore section.
- Hazelcast Striim Hot Cache Adapter: Hot Cache functionality based on Striim's Change Data Capture (CDC) for the underlying database updates. Please note that this enhancement is available for Hazelcast Enterprise. Please refer to the Hazelcast Striim Hot Cache section.
- One-off WAN Synchronization with Dynamically Added Endpoint: Improvement to allow copying the maps' all content to a target cluster dynamically in runtime. Please note that this enhancement is available for Hazelcast Enterprise.
- Hot Restart Usability Improvements: When a cluster with Hot Restart enabled is restarted, it starts in the ACTIVE state. Please note that this enhancement is available for Hazelcast Enterprise. Please refer to the Hot Restart Types section.
- Hot Restart with Incomplete Members: The restart procedure for a cluster having Hot Restart enabled is now more flexible by allowing you to do a partial start, which basically means that once the cluster is shutdown, it can be restarted with some missing members. Please note that this enhancement is available for Hazelcast Enterprise. Please refer to the Partial Start section.
- Copy Hot Restart Store data from Source to Target: You can copy Hot Restart Store data from a running cluster to a target without shutting down the source cluster. Please note that this enhancement is available for Hazelcast Enterprise. Please refer to the Hot Backup section.
- Improvement in WAN Queue Full Behavior: Now, Hazelcast throws an exception when the queue is full and replication is active, unless it is stopped on the Management Center. Please note that this enhancement is available for Hazelcast Enterprise. Please refer to the Queue Full Behavior section.
The following are the other improvements performed to solve the enhancement issues opened by the Hazelcast customers/team.
- Currently there are only MERGING and MERGED states for lifecycle, but no event is fired for a failed merge. This would be informative and further give an idea to user to understand a reason of a SHUTTING_DOWN event since a failed merge is followed by a shutdown. 
- Tests are needed to prove that
removeAlldoes not deserialize portables. 
- Client support for distributed scheduled executor service. 
- When a member without JCache service joins a cluster where JCache service is enabled but not used, the member should not fail. 
- It would be nice to have names assigned to all threads created by Hazelcast (and not the default ones, e.g.,
- There should be a more detailed and clarifying information in the diagnostics of
- When there is no access to
NodeEngine, the logger should be able to be used from a static context without any side effects to the logging configuration. 
- Client tasks should be bounced back when a member has not completely start yet. 
- A method
size(Predicate)should be added to determine the size of predicate results. 
- Currently the property
com.hazelcast.map.impl.eviction.ExpirationManager.PERIODis hard-coded to 5 seconds. Making it a configurable property will help in tuning the eviction. 
- The method
com.hazelcast.topic.impl.TopicProxy#publishserializes the message even if the message is never sent due to having no subscribers. In the case of non-global-ordering and non-client use, the implementation should defer serialization until it has established that there are subscribers. 
- Hazelcast should provide an abstract Mapper implementation which invokes the Supplier given to
- Configuration setting for WAN replication queue should be only for primary entries. 
- Currently if you want to use Container-Managed Transactions with Hazelcast within a JEE Application Server, you need to use the provided JCA Adapter. This JCA Adapter creates a Hazelcast instance. This should be allowed: configuration of the JCA Adapter to be either Server or Client-based. 
PartitionIteratingOperationconsumes a generic operation thread, while the operations for the partitions are running. This means that the generic thread pool can dry out and this can cause a lot of problems for important tasks that cannot be executed since the thread pool is empty. A
PartitionIteratingServiceshould be introduced where the system can lookup TraceableOperations. 
- Hazelcast Shutdown Hook calls the method
- Hazelcast should support
The following are the issues solved for Hazelcast 3.8 release.
TaskDefinitionshould be removed from the client protocol. 
AggregationResultshould be serialized via Codec instead of IDS. 
MetaDataResponseshould be serialized via Codec instead of IDS. 
- The script
stop.batdoes not stop the running Hazelcast instances. 
- The script
start.batallows multiple instances to be started in the same folder; it should not. 
- Ordering consistency for the the method
writePortableshould be explained in the Reference Manual. 
- A client cannot add index to map using Portable values without registering Portable classes on member. 
- Index is not updated after entry processors change values. 
- When using Entry Processor and index on a field the Entry Processor uses, wrong data is returned when executing a Predicate. 
LockServiceImpl: an NPE is thrown in
LockServiceImplwhen creating one map with a quorum configuration (which activates the
QuorumAwareoperations) and then calling a
QuorumAwareoperation on another data structure without a quorum configuration. 
ClusterVersionis missing convenience methods for comparing easily. 
- When scheduling tasks with multiple executors, calling
getAllScheduledon one of them returns tasks scheduled per member but for all executors, rather than for the one we called the
- There are too many log entries when quorum is not present. 
- Hazelcast terminates listener incorrectly. 
deleteAllmethods are used in the MapStore interface, it is possible that the underlying implementation has stored/deleted some entries from the supplied batch and then gets an exception on some particular entry in the middle of the batch. In order to handle this scenario properly the MapStore could remove from the supplied batch entries which were properly stored in the underlying persistent store. The only thing to improve in the
DefaultWiteBehindProcessoris to properly synchronize the map passed to
processBatchmethod with the initial
hazelcast.discovery.enabledon the client side: If neither
DiscoveryStrategyConfigis specified, an NPE is thrown. A more helpful exception should be provided. 
hazelcast-all.jar, which is the one included in Hazelcast Docker, downloaded from Maven repo, contains an outdated version of
- When scheduling on random partitions and trying to get all the scheduled tasks from the service, the number of tasks is wrong. The returned figure seems to match "num_of_tasks * backup_count". 
- When a scheduled Callable/Runnable throws an exception, invoking
future.get()on the client side does not throw the expected
- The client is not updating listener registrations when the member restarts with a new version. 
IScheduledExecutorServicedoes not use
HazelcastInstanceAwareon local operations. 
- Near cache compatibility with 3.7 clients is broken for TTL expirations. 
- Fix inconsistent Ringbuffer TTL defaults: when starting a
HazelcastInstancewithout an explicit configuration (
HazelcastInstance hz = Hazelcast.newHazelcastInstance();), the default Ringbuffer TTL was 30 seconds, instead of correct value 0. This change may break existing applications relying on the default configuration. 
- Replicated Map configured with
falseprevents further members from joining the cluster. Members are stuck in an endless loop. 
- When an exception is thrown from an
InitializingObject's initialize method, it is logged in WARNING level but then swallowed and the proxy object is added to the
ProxyRegistry. Instead, the exception should result in removing the object from the
ProxyRegistry, as it is already done for exceptions thrown from
- Near cache pre-loader fails when invalidations are enabled. 
- There is a memory leak in
MetaDataGeneratorwhen (1) near cache invalidations are enabled, (2) map/cache is created and destroyed, and (3) the map name is stays referenced from
- JCache client needs access to
CacheLoaderimplementation to work. 
- The matching wildcard is strict, but no declaration can be found for element
- "Connection Reset" warning shows up in the class
- Key state marking in near cached
getAllshould be improved. Instead of key based marking, partition based approach can be used. 
- Scheduled executor service tests are too slow. 
- The method
getAllis not updating the
- Hazelcast 3.7.3 and Spring Boot 1.4.2 get the error
PortableFactory[-22] is already registered. 
- There is an issue when integrating with WebLogic 12c. Classloading logging should be added when
DefaultNodeExtensionis loaded by multiple classloaders. 
- The method
MapLoader.loadAll(true)does not reload after reloading with new keys. 
- Problems with timeout in blocking calls. 
- Stale reads from Map inside a transaction should be guaranteed, when Near Cache and delayed MapStore are enabled. 
- Client protocol cannot handle "null"s in the collection. 
LifecycleStateevents are not received when Hazelcast docker image is used. 
- If there is no network, multicast socket exception is thrown. 
- Hazelcast is not handling XML configuration attribute for
DurableExecutorService.retrieveResult(long)is run from a client for a task that does not exist, two exceptions appear at the client side. At the member side, it logs
StaleTaskIdException. This should not be logged to the member if re-thrown to the client. 
- When retrieving data from Java Hazelcast instance,
HazelcastSerializationExceptionis thrown from the .NET client. 
- Callback for time to live (for map eviction) is invoked with a significant delay. 
- "Warning 2" in
IMap::tryRemovemethod's code comments is not correct. This method returns only a boolean. 
- There are too many log messages when members of a cluster are not joined to another cluster (multicast) having a different group name in Hazelcast 3.6 and 3.7, which is already expected. 
- When clients lose connection to the members in the cluster, even after the clients are reconnected to the cluster, the Entry/Message Listeners are never fired again. 
- Nested queries on
VersionedPortableswith different versions cannot be performed. Hazelcast throws IllegalArgumentException. 
max-sizevalue behavior for Near Cache configuration. If you set 0 for the
max-size, now, it is valued as
Integer.MAX_VALUEas expected and documented. 
- While generating the XML string from a configuration object in
native-memoryconfiguration is not appended to the result string. This causes the
native-memoryconfiguration for members not to be shown on the Management Center. 
- "Client heartbeat is timed out , closing connection" warning shows up indefinitely on AWS. 
- Spring XML configuration: The smart routing attribute defaults to false while the documentation says it defaults to true. 
- Distributed objects present in the cluster do not show the same values. 
- In Hazelcast 3.6.3, the error
Current thread is not owner of the lockshows up when using Hazelcast client to perform the actions. 
- There is an unchecked
CancelledKeyExceptionwhen client disconnects from the cluster. 
getoperation with 100 keys fails. 
IllegalThreadStateExceptionmay be thrown sometimes on a member of a cluster with two or more members when a Hazelcast client creates a new map with configured indexes. This exception is not thrown when indexes are created programmatically. 
- Group and password attributes in Hibernate integration module should be validated. 
- There appears to be an inconsistency where JCache uses the
EvictionConfigobject, but IMap directly uses properties of the
- Topic listeners are lost after merging from a split-brain scenario. 
- Member attributes go missing after merging from a split-brain scenario. 
- There should be a distributed class loading feature to perform distributed loading of classes so that jobs like MapReduce and Aggregate can be done more effectively. 
- MapLoader misses state updates on second load on the receiver members. 
- If the system retries an operation because a member is leaving the cluster, the invocation can be retried due to the response but also due to the "member-left" event. In most cases this should not lead to a problem, but the invocation may be executed twice. This can be a problem and can lead to a permanent inconsistent system. 
- Using Lock and Map, the heap memory on Hazelcast server keeps increasing. All the created Locks and Maps are destroyed by the method
destroy(), but the memory cannot be destroyed by the garbage collector even via FGC. When an application runs for some time, Hazelcast server goes down. 
- Hazelcast 3.5 throws
- More granular mutexes should be used when creating and removing a set of closeable cache resources. 
PredicateBuilderqueries when nodes join causes timeouts and cluster crash. 
- The method
setEvictionPolicyfor near cache configuration wants a string argument whereas the same for map configuration wants an enum value. 
- The configuration schemas Hazelcast Spring XSD and Hazelcast default configuration XSD are out of sync. They must have the same elements. 
- Aggregators feature is deprecated. Instead, Fast-Aggregations feature should be used.
- MapReduce feature is deprecated. Please refer to MapReduce Deprecation section.