IMaplock. What I am seeing is that if I have a two node cluster running (
node-2). Each node is attempting to acquire a lock using multiple threads. I observe the lock being released on
node-2leaves the cluster shortly afterwards. It looks like the backup is resurrected preventing any other threads from obtaining the lock (unless by chance it was a thread on node 1 that originally acquired the lock in which case the
LockResourceImpl#lockCountgets incremented to
2and back down to
1when it is released. I can tell this is the same lock that was earlier released because I set some debug points in the
LockResourceImpland print out the
acquireTime. We are currently running hazelcast 3.11.1 and I have verified the same behaviour on hazelcast 3.11.4 is this a known issue? Expected behaviour? Is there a system property I can set that requires replica ack of lock operations? Upgrading to 3.12.1 and switching to fenced locks is not a possibility for us at this time. Would setting a quorom help? the number of the nodes in the cluster is dynamic scaling from 1-30 so I don't know how we would configure that. I am happy to write up more details on a github issue, if this is a genuine issue
starting with Hazelcast Enterprise 3.8, each next minor version released will be compatible with the previous one. For example, it will be possible to perform a rolling upgrade on a cluster running Hazelcast Enterprise 3.8 to Hazelcast Enterprise 3.9 whenever that is released.
Is there any plan to support rolling upgrades between non-subsequent minor versions in future?
For e.g. 3.8 and 3.11 ?