HazelcastClusterManager#getAsyncMultiMap memory leak

[michalsida]

Repeating call cause probably a memory leak. In this call is created a new one HazelcastAsyncMultiMap - a wrapper for Hazelcast MultiMap, it is stored into weak set and send it to the result handler. So if the result handler throw the reference away, it should be removed from weak set too.

But.

There is a call of com.hazelcast.core.MultiMap#addEntryListener(this, true) in the HazelcastAsyncMultiMap constructor, which will store a strong reference to the object to some Hazelcast's ConcurrentHashMap of registered listeners. And it will prevent a garbage collecting of HazelcastAsyncMultiMap instance (and referenced data/objects), which is unused by result handler already.

Detected in version: 3.5.0

[vietj]

can you investigate @tsegismont ?

[tsegismont]

@michalsida nice catch!

This is an area where we would like to improve the ClusterManager SPI. The SPI grew out of the initial Hazelcast implementation, and the getAsyncMultiMap leaked out to ClusterManager so that ClusteredEventBus can get one to store handler registrations. It wasn't intended as a user-facing method, but here it is now...

The good news is that ClusteredEventBus never calls this method more than once, so you should be safe in your project. Until we review the ClusterManager SPI, I would like to add a close or dispose method to AsyncMultiMap.

Hazelcast (and Infinispan) cluster manager would use that method to remove the listener.

[michalsida]

I needed this method for some (a little dirty) hack of other project and I started to use it the same way (= call it only once).

[tsegismont]

@vietj I sent a PR to core as well as HZ and ISPN cluster managers.
@michalsida please take a look as well

[tsegismont]

@michalsida is this workaround still needed after the fix for vert-x3/vertx-hazelcast#90 is merged in master?

[tsegismont]

Closing as vert-x3/vertx-hazelcast#90 should remove the need for creating many multimaps.