IMap.destroy() is flaky (?)

Question

Context:

• Hazelcast 3.4.1
• 2 Hazelcast nodes
• Both nodes runs the same Hazelcast-related code
• Each node in its own Java process
• Both Java processes runs on the same server
• The configuration required one backup (1

What's happening

At T0, one of the node delete a map and it works all the time The map is no longer visible in the Management Console (MC)

IMap<String, IMyStuff> aMap= getHazelcastInstance().getMap("a particular map");
aMap.destroy();

At T1, Node A perform "cleanup task" that make sure that some maps are empry & destroyed:

IMap<String, IMyStuff> aMap= getHazelcastInstance().getMap("a particular map");
// clean-up / validation stuff
aMap.destroy();

Since the map does not exist anymore, getMap(...) return a new and empty one - works as expected.

At this point, the map is still destroyed (not visible in MC)

At T2, Node B perform the same "cleanup task" (for redundancy)

IMap<String, IMyStuff> aMap= getHazelcastInstance().getMap("a particular map");
// clean-up / validation stuff
aMap.destroy();

The problem

After T2, sometime (between 5-50%) of the time, the map "a particular map" is still visible in the MC and it should not. Looking closely at the "Map XXX Data Table" in MC, it appear that the map is only on Node B, but not in Node A, although it is configured for a single (synchronous) backup.

I look like the DistributedObject.destroy() call is not honored in all cases.

The question

Is anyone ran into this issue? It look like a bug , but might miss something, ex: should it a a minimum delay between the getMap(...) that create an empty Map and the destroy()?

I know that synchronous backup make sure the item is added in all the necessary node before returning, is it the same for Map creation.

Thanks for your help,

-Martin

Answer 1

Stumbled here via search. It could be a bug in Hazelcast version: 3.4.2, 3.5 which has been fixed in 3.6 https://github.com/hazelcast/hazelcast/issues/5554