4.0
Changes introduced in 4.0 with links to their pull requests.
- Client protocol
- Distribution
- Hot Restart
- CP subsystem
- REST API
- Query
- Security
- WAN replication
- Migration from ICompletableFuture to CompletionStage
- Non-volatile Persistent Memory support (EE)
- Serialization Enhancements
- Removed Legacy Merge Policies
- Renamed group-name as cluster-name
- Renamed Quorum as SplitBrainProtection
- MapLoader with Custom TTL
- Hazelcast Instances: Using Moby naming
- User Defined Services SPI removal
- Refactoring of Migration Listener
- Client backup acknowledgment improvements
- Removal of Deprecated Classes
- Concurrency API Clean-up
- Removal of MapReduce
- Package Cleanup
- IdentifiedDataSerializable.getId rename
- Optimize HZ for Single Threaded Situation
- TLS OpenSSL + increased IO threads by default
- Transaction Commit Fails on WriteBehindQueue Exception
- Smart client default IO threadcount increase
- IO Optimization - NioThread pipeline scheduling
- Member default IO threadcount increase >= 20 cores
- Client Architectural Improvements
- Ownerless Client
- Dynamic metrics collection
Currently to use the CP subsystem, at least 3 nodes are required. But this requirement makes it difficult to test and develop applications. Also, some users do not need the safety guarantees of a CP system but just need the functionality of data structures exposed by CP subsystem with one or two nodes. With Hazelcast 4.0, we allow access to CP data structures even with a single node without providing strong safety guarantees. This mode is called the “unsafe” mode and it replaces concurrent data structures previously deprecated in Hazelcast 3.12 (ILock, IdGenerator, IAtomicLong, IAtomicReference, ICountDownLatch, ISemaphore).
CP Subsystem Persistence enables CP members persist their local state to stable storage. This capability significantly improves the overall reliability of CP Subsystem by recovering from member and cluster crash scenarios, without sacrificing safety guarantees. Our entire CP subsystem implementation, including the CP subsystem persistence feature, is fully covered by the Jepsen testing framework.
Introduced a REST API endpoint that makes it possible to update the license on a running cluster.
You can now more naturally access HazelcastJsonValue instances stored in your map via the REST API. The response will be a UTF8 encoded JSON values with the Content-Type header set to application/json.
-
replace
<group>configuration by simple<cluster-name> -
introduce the concept of security realms
-
add typed authentication and identity configuration (e.g.
<ldap>authentication,<token>identity) -
use similar identity configuration in client config
Two new JAAS login modules are introduced to authenticate against LDAP servers.
-
Make TLS peer certificate chain available for later reuse;
-
Provide JAAS Callback to retrieve the peer’s TLS certificate chain in login modules;
-
Provide out-of-the-box login module which can parse Principal names from attribute(s) in the client certificates
-
follow JAAS best practices;
-
avoid automatic deserialization of custom credentials in the client protocol
-
introduce a concept of security roles to distinguish between (a single) connecting side identity and its privileges;
-
use Credentials object only for authentication to prevent secrets leaks;
-
cleanup Credentials interface;
Host identity validation can be enabled for TLS connections. New true/false property validateIdentity is supported in Hazelcast-provided TLS factories - JSSE and OpenSSL/BoringSSL. Default value is false.
Once enabled it configures newly created SSLEngine instances to do host identity validation on client-side of TLS connections. Only certificates with matching SAN (Subject Alternative Name) entries for given hostname or IP address are allowed.
The algorithm used for matching endpoint identity is the HTTP one described in RFC-2818 section 3
We added HTTPs support to cluster.sh, healthcheck.sh and cp-subsystem.sh management scripts.
In 3.x, the WAN publisher SPI allows the user to plug into the lifecycle of a map/cache entry and replicate the updates to another system. For example, we have an integration with the Solace message broker (https://github.com/hazelcast/hazelcast-solace). A user might implement replication to Kafka or some JMS queue or even write out map and cache event changes to a log on disk. The issues with the previous SPI were:
-
multiple interfaces to implement
-
leaking internals in public SPI
-
different interfaces for WAN replication events, depending on OS or EE
-
unused methods
-
private classes exposed in public package
The goal is to clean up and simplify the SPI that needs to be implemented by the user.
Currently, there is no way of evolving WAN as there is no cluster information/metadata sent between the source and target cluster. This makes it very hard to implement new features on top of WAN or optimise the format of the data sent from the source to the target cluster. Because of this, we need to introduce a protocol with which the clusters can negotiate the set of supported features and the version of the protocol supported by the target cluster. After an initial connection is established, ideally the protocol should:
-
send cluster information from the source to the target cluster
-
the target cluster should respond by sending its cluster information
-
this negotiation needs to be done periodically since both the source and target cluster version and capabilities may change over time (rolling upgrades)
-
both the source and the target cluster may contain multiple implementations of different versions of the WAN protocol, allowing us to keep indefinite backward compatibility
Configuring WAN can be a bit difficult.
-
the user needs to list the fully qualified class name of the WAN implementation that should be used. In most cases, this is our internal implementation and will always be the same
-
there are various configuration options, some of which are present as java class instance fields or XML nodes and attributes with javaDoc, others are present in a properties list where the user needs to correctly copy the property name without any IDE help. If there is an error in the property name, it will not be detected
-
if the user wants to use a custom WAN publisher SPI implementation, some configuration options don’t make sense as they are tied to our implementation (e.g. WAN queue size) it is quite verbose
The goal is trying to address the issues above by providing both simple and safe ways of configuring WAN, when our built-in implementation and when using a custom implementation. This change deals solely with simplifying WAN replication configuration and making it more natural and easier to use. There is no new functionality provided to the user.
We have introduced better tracking of the state and the progress of WAN synchronization requests. This is most visible when using the Management Center to trigger and track the progress of the WAN synchronization. Now, you can even see the results for previous WAN synchronization requests or even for overlapping synchronization requests.
In Hazelcast 3.x series, com.hazelcast.core.ICompletableFuture was introduced to enable reactive programming style. ICompletableFuture was intended as a temporary, JDK 6 compatible replacement for java.util.concurrent.CompletableFuture that was introduced in Java 8. Since Hazelcast 4.0 requires Java 8, ICompletableFuture is now removed. Async Hazelcast API methods return java.util.concurrent.CompletionStage which allows for chaining of further computation stages. Using CompletionStage.toCompletableFuture() allows interoperability with other frameworks that use CompletableFuture.
The goal is to support non-volatile persistent memory for data structures like IMap, ICache and NearCache. With minimum configuration changes and no application code changes customers would be able to use Intel Optane DC memory as off-heap HD memory. There is no need to install any third-party libraries to use Intel Optane DC, all necessary libraries are delivered with Hazelcast 4.0 distribution.
-
#15238 Support 4-byte UTF-8 serialization.
-
#15371 Added built-in support for various Java collection types. These types are: Added the following Java default serializers.
-
ArrayDeque
-
HashSet
-
TreeSet
-
TreeMap
-
LinkedHashSet
-
LinkedHashMap
-
LinkedBlockingQueue
-
ArrayBlockingQueue
-
PriorityBlockingQueue
-
DelayQueue
-
SynchronousQueue
-
LinkedBlockingDeque
-
LinkedTransferQueue
-
CopyOnWriteArrayList
-
CopyOnWriteArraySet
-
ConcurrentSkipListSet
-
ConcurrentHashMap
-
ConcurrentSkipListMap
-
We’ve removed the merge policies specific to each data structure. Now you can use the generic merge policies introduced in 3.10. For further info please see Removal of Legacy Merge Policies section of migration guide.
We’ve added the capability to load and store expiration times when loading and storing entries using MapLoader and MapStore. Existing MapLoader and MapStore implementations should continue to work normally but if you need to handle expiration times, you can implement the new EntryLoader and EntryStore interfaces.
When starting Hazelcast members, each instance would get assigned a generated instance name. Different members are similarly named and when monitoring a cluster through the Management center it can get difficult to distinguish between different members. We now provide more human-readable (and fun!) names using Moby naming - names such as hopeful_turing, jovial_chatelet or brave_driscoll. Since the instance name will be new after restart it will be easier to track member restarts in logs.
We’ve removed support for adding user-defined services. The reason was that this SPI was not clearly defined and backwards-compatiblity was broken in some occasions due to the fact that the SPI was too complex. This gives us more freedom when evolving Hazelcast and it also gives us an opportunity to provide a new SPI in the future, should there be enough interest. We will still keep the same classes (and we will use them internally) but we will not provide any compatibility guarantees.
We’ve redesigned the MigrationListener API to be more intuitive. Previously, on each migration a pair of migration started and migration completed or failed events were fired but this level of detail is not relevant to most users. Now, we send events when the overall migration process starts, when each partition is migrated and when the overall migration process completes. On each step, you can see how many migrations are planned, how many have completed, how much time has elapsed etc.
#15758, #15742, #15743, #15330, hazelcast-hibernate5#63, #15335, EE#3084, #15091, #15679, EE#3228, #15678, EE#3207, #15651, #15701, #15674, #15719, #15676, #15680, #15720, #15721, #15730, #15729, #15728, #15773, #15781
There were a number of deprecated and outdated public API and SPI classes which were kept only for backward compatibility. Some of them are no longer used in Hazelcast itself, while others have a better alternative. We’ve now removed those classes.
We’ve removed map reduce. For a more complete, versatile and powerful alternative, please take a look at Hazelcast Jet or the Aggregations that uses the Query infrastructure.
15569, 15570, EE#3163, 15588, EE#3171, 15599, EE#3173, 15603, EE#3176, 15616, EE#3178, 15171, 15151, EE#3042, 15146, EE#3030, 15145, 15129, EE#3018, 15124, EE#3015, 15123, EE#3014, 15122, EE#3013, 15121, EE#2933, 15888, EE#3292, 15887, EE#3290,
We clearly separated lots of private API classes from public packages. Private API should now be located in packages containing “internal” or “impl”.
If the system detects that OpenSSL is available, then it will be enabled by default unless something has been configured otherwise. By default we increase the IO threadcount to processor_count/2 so we’ll get as many IO threads as there are processors (internally we multiply by 2 because we have input threads and output threads). SSL encryption and decryption is very CPU intensive and the default of 6/8 IO threads isn’t sufficient in case of key/value based usages. This PR changes that so we apply our recommendation as an out of the box setting. If for whatever reason this gives a performance regression, then use the following system property to revert to the defaults: -Dhazelcast.io.thread.count=3 when less than 20 processors -Dhazelcast.io.thread.count=4 when equal or more than 20 processors.
Prevents transactional maps inconsistent behavior when WBQ back pressure is enabled.
Previously, the clients had an owner member responsible for cleaning up their resources after they leave the cluster. Also, the ownership information was needed to be replicated to the whole cluster when a client joins the cluster. This mechanism have been made simpler by introducing the following system properties to control the lifecycle of the clients on the member side:
-
hazelcast.client.cleanup.period.millis -
hazelcast.client.cleanup.timeout.millis
15560, 15650, EE#3197, 15667, EE#3204, 15779, EE#3241, 15782, EE#3274, 15818, 15607, 15655, 15917, EE#3314, 15926, 15933, 15682, 15963, 15988, 15993, 16040, 16070, 16093, 16094, EE#3384
Previously, Hazelcast metrics were reported programmatically to the Hazelcast Management Center, one by one. Introducing new metrics required changes both in IMDG and in MC, which limited the number of metrics sent to MC. In 4.0 this has been changed to collecting and reporting all available metrics dynamically just by declaring them in IMDG. Besides reporting the metrics dynamically to MC exposing them on JMX is done dynamically as well. Both reporting to MC and exposing on JMX are toggleable by using the metric configuration element introduced in 4.0.