Memory leak with org.springframework.integration.hazelcast.leader.LeaderInitiator

[mleguevel]

Hello,

I think that the hazelcast LeaderInitiator causes a memory leak. The reason for this is that it's calling tryLock twice before calling unlock and continuing with tryLock / unlock.

When doing this, an internal Map in hazelcast keeps growing while the LeaderInitiator keeps calling tryLock and unlock. This Map can be found either in com.hazelcast.cp.internal.datastructures.lock.RaftLock for the version 3.12.9 of hazelcast or in com.hazelcast.cp.internal.datastructures.lock.Lock for the version 4.0.3. I've reproduced the problem with both versions.

I first created an issue in hazelcast repository and their conclusion seems to be that it works as designed.

Can this be considered a bug in LeaderInitiator then?

Thank you.

[artembilan]

Hi, @mleguevel !

I'm not fully sure what is going on, but if you raise a Pull Request with the fix and some test to confirm that there is no problem and everything else works as designed (all other tests passes), I'll accept such a contribution with a great pleasure.

More over it would be great to have a fix since we are heading to release with Hazelcast extension soon enough.

Thank you!

[mleguevel]

Hi @artembilan

I created a PR: #236
I'm not entirely sure that it's totally equivalent to the previous algorithm though. But the LeaderInitiatorTest tests pass.
I removed the two additional hazelcast instances from the test class because I assumed that they were added to circumvent the bug that prevented hazelcast from starting in unsafe mode in the 3.12.X versions. Tell me if it's not the reason.