• Home
• com.hazelcast
• hazelcast
• 3.7-EA
• source code

×

Project download

Many resources are needed to download a project. Please understand that we have to compensate our server costs. Thank you in advance.
Project price only 1 $

You can buy this project and download/modify it how often you want.

.hazelcast.3.7-EA.source-code.release_notes.txt Maven / Gradle / Ivy

In this Release Notes document, you will find the new features, enhancements and fixes of the Hazelcast 3.7 release.
The numbers in the square brackets refer to the issue number in Hazelcast’s GitHub repository. You can reach
to the full descriptions of the issues at https://github.com/hazelcast/hazelcast/issues/.

1. New Features
This section provides the new features introduced with Hazelcast 3.7 release. 

- Custom Eviction Policy: You can implement and use your own eviction policy. Please refer to the Custom Eviction Policy section.

- ???

_ ???

2. Enhancements

This section lists the enhancements performed for Hazelcast 3.7 release.

- ???: ???. Please refer to the ??? section.


The following are the other improvements performed to solve the enhancement issues opened by the Hazelcast customers/team.

- The performance log should have an option to log to the 'shared' logger instead of its own file. It would be useful for environments where Hazelcast cannot create or get a performance log file. [7973]

- The path for performance logs, which is currently fixed to the user's working directory should be configurable. [7968]

- Hazelcast IAtomicLong data structure provides synchronous methods only; async versions already exist and are available to Hazelcast members via AsyncAtomicLong interface. Lack of public a async API for IAtomicLong is impeding Hazelcast integrations. [7957]

- It would be better to have a way where near cache notifications for each entry are disabled, but an ability to enable/disable notifications of full-flush events (clear, etc.). [7580]

- Hazelcast should support Transaction API of Spring. [7469]

- For Hazelcast Topic, even the event service's pool size is set to a number larger than one, all of the messages are consumed by only one Hazelcast event thread. The use case includes a single Hazelcast member, both producer and consumer being singletons within the member, and message rate of more than 1000 per second. [7443]

- Async put operations should be reflected at near cache as soon as the method future.get() returns. In the case of async put operations and LocalUpdatePolicy being CACHE at the client side, entries are put to the near cache asynchronously from another task when the response is received. But with this way, when future.get() returns, entry might not be inside the near cache (but it will be there eventually). [7155]

- ICache.iterator() fetchSize is not configurable. [7041]

- Unit tests should have a default timeout. [6978]

- Outgoing ports on Hazelcast clients should be configurable. [6845]

- The method IMap.set does not have a corresponding async version, unlike put and putAsync. The method putAsync is not entirely suitable as an async set, since put returns the previous value mapped to the key, and triggers EntryListeners which may not be desirable. IMap should expose a dedicated setAsync to fulfill the contract for set and have the means to do so asynchronously. [6726]

- The "spring-aware" should be enabled programmatically too. [6514]

- It would be nice if the type parameters of Predicate were inherited by the IndexAwarePredicate. [1686]

- The class MigrationEndpoint should be a part of Hazelcast SPI package. [1427]

- When a task is submitted to all members, and an executeOnEntries is invoked in the call with a predicate that is based on an index, then the index is ignored and a "full scan" of the "local" members is performed. [1156]

- Inconsistency between the declarative and programmatic configuration of network elements should be solved. [945]



3. Fixes

The following are the issues solved for Hazelcast 3.7 and 3.7.x releases.

*3.7 Fixes*

This section lists the fixed issues for 3.7 release.

- The method ICache::destroy should remove the cache itself from the owner CacheManager because, otherwise, it causes memory leaks due to the cache proxies which are dead but deemed as working, in AbstractHazelcastCacheManager::caches. [8186]

- Partition promotion is skipped when a node is terminated during the commit. [8174]

- The method IAtomicReference:alter does not persist the changes. When a reference is tried to be altered, no alteration happens. [8149]

- Cache should not expire entities when Duration value is 0. [8148]

- The attribute "binary" is missing in the MultiMap configuration within Spring context. It does not exist in Hazelcast configuration schema either. [8000]

- If you setup an interceptor to change the data being inserted, the entry listeners still fire with the old value. [7991]

- Unlike the InvocationFuture at the server side, ClientInvocationFuture immediately propagates InterruptedException if the calling thread gets interrupted. This can be a problem when both caller and callee need to agree on whether the operation has executed or not. [7963]

- Hazelcast 3.2.6 uses too much CPU when it is idle. [7943]

- There is an issue when detecting JCache in the classpath. The exception NoClassDefFound is thrown when upgrading to a newer Hazelcast version. [7810]

- Better separators should be used in the exceptions for a clearer read between local and remote stacktraces. [7744]

- Under the section "Operation Threading" of Hazelcast Reference Manual, it states that the default number of partition-aware operation threads is (2 x number of cores). However, when looking at the code and observing the actual number of threads created runtime, it seems like the default value is instead 1 x number of cores instead. [7741]

- The method IMap.executeOnKeys() does not support the empty set (it throws a misleading NullPointerException), and is inconsistent with the method getAll(). [7631]

- Replicated map updates take a very long time. The problematic method is putAll(). The replication logic in this method checks whether the data owners are in sync with the replicas. If they are not, this logic syncs them every 30 seconds. This means, when the updates are not replicated to callers, it takes up to 30 seconds to make all the members synchronized. This period should be configurable. [7617]

- ScheduledExecutorServiceDelegate violates contract of ScheduledExecutorService. It wraps tasks in ScheduledTaskRunner which delegates to a different executor. As a consequence, a task can be executed concurrently and this is a violation of a contract of ScheduledExecutorService. [7611]

- If javax.cache.CacheManager is created with the default settings, the underlying HazelcastInstance is not shutdown when the method close is called on the CacheManager. [7606]

- There is an inconsistent behavior when removing from TransactionalMap while the key is locked on IMap. In order to avoid trying to remove an entry that may have already been removed in another uncommitted transaction, IMap.tryLock is used before performing TransactionalMap.remove. This works as expected if the operations occur on a member. But a TransactionException is thrown when it occurs on a client when using XA Transaction. [7587]

- Hazelcast instance should be exposed through com.hazelcast.spring.cache.HazelcastCacheManager. [7571]

- Instance name should not be overridden while creating cache manager from the specified configuration file. Also, it would be better to specify instance name via (]HazelcastCachingProvider.HAZELCAST_INSTANCE_NAME property when instance configuration is taken from the specified configuration file via HazelcastCachingProvider.HAZELCAST_CONFIG_LOCATION.[7567]

- The addInterceptor() method in com.hazelcast.map.impl.MapContainer() is not thread safe. For example, if two concurrent attempts are made to inject the same interceptor, these will be different interceptor objects with the same ID. In this case, the call to interceptorMap.put(id, interceptor) will increase the map size by one, but the call to interceptors.add(interceptor) will increase the list size by two. [7520]

- There are unused elements for Management Center configuration: cluster-id and security-token. [7446]

- For clients, InitialMembershipListener.init is called after MembershipListener.memberAdded. This contradicts the content in the Reference Manual. [7430]

- DiscoveryService's start and destroy methods should be called during the start and shutdown of client when Discovery SPI is enabled. [7347]

- Return cache config as response even though found and created cache config could not put into cache configs inside cache service. [7208]

- In Hazelcast Management Center shutting down a node seems to prevent a node from restarting. [7101]

- Data is lost when the member dies during repartitioning. [6628]

- When the client disconnects normally, the server logs an info and a warning message containing the text java.io.EOFException. [6035]

- Some operating systems (such as HPUX or Solaris) and hardware platforms have constraints about the aligned memory operations. In these architectures memory operations must be byte-by-byte as implemented in DirectByteBuffer. [5532]

- As for now it is very complicated to listen a getAsync or putAsync result and to integrate it with completable futures or listenable futures. An ICompletableFuture should be returned since it is an interface which seems to extend JDK futures and is returned by an IMap. [5315]

- ClassNotFoundException is thrown when trying to get an entry from a TransactionalMap. [4969]

- Profiling a Hazelcast application reveals a thread contention in SpringManagedContext on java.lang.Class.getAnnotation(). And this calls a synchronized method called initAnnotationsIfNecessary(). [4506]

- Hazelcast IMap statistics show negative values. After heavy usage of the cache, the number of misses starts showing up negative. [4022]

- When there is a map with write-behind mode and a map store is configured (eviction is not needed); when the method flush is called in the IMap, the map store's store method can be called concurrently for the same key, namely for those keys which are in the write-behind queue and then forcibly stored by the flush. This is because the flush operation storing all entries in the write-behind queue seems to be executed in the operation thread, while the periodic processing of the write-behind queue is done by an executor service defined in the WriteBehindQueueManager. [3338]