ILock to FencedLock issue while Hazelcast upgrade from 3.12.6 to 4.0.1

[Yogesh Sonune]

Hi,
We are in migration phase of Hazelcast version 3.12.6 to 4.0.1 for one of production deployed application which run on 2 instance (2 hazelcast nodes) on differnet servers.

In version 3.12.6 we was using ILock and as per migration guideline for 4.0.1 we started using FencedLock.

But issue while using version 4.0.1, to enable CP subsytem requires atleast 3 hazlecast nodes our application has 2 hazelcast nodes and in disable mode it not provide strong consistency gurantee.

We require strong consistency gurantee as we are using Lock for one of critical condtion. We have still have option to use Imap.Lock but Imap not provides method which provided by FencedLock like isLockedByCurentThread() etc.

So could you please suggest possible suggestion on above issue

Thanks and regards
Yogesh

[Mehmet Dogan]

Hi,

FencedLock in unsafe mode has the same & weak consistency guarantees as the former ILock. ILock was not providing any kind of strong consistency. So if you are fine with ILock, then unsafe/non-CP FencedLock will work for you too. 

If you really need strong consistency then you should really enable the CP subsystem with at least 3 nodes.

- Mehmet Dogan -

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/2285a122-c12b-4038-b3b5-2677ca6f9e27o%40googlegroups.com.

This message contains confidential information and is intended only for the individuals named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required, please request a hard-copy version. -Hazelcast

[Yogesh Sonune]

Hi,

We are in migration phase of Hazelcast version 3.12.6 to 4.0.1 for one of production deployed application which runs on 2 instances (2 hazelcast nodes) on different servers.

In version 3.12.6 we were using ILock and as per migration guideline for 4.0.1 we started using FencedLock.

But issue while using version 4.0.1, to enable CP subsystem requires at least 3 hazlecast nodes but for our application using only 2 hazelcast node and in disable mode it not provide strong consistency guarantee.

We require strong consistency guarantee as we are using Lock for one of critical condition. We still have option to use Imap.Lock but Imap not provides method which provided by FencedLock like isLockedByCurentThread() etc.

 

So could you please suggest possible solution on above issue?

[yogesh....@gmail.com]

Hi,

We are in migration phase of Hazelcast version 3.12.6 to 4.0.1 for one of production deployed application which runs on 2 instances (2 hazelcast nodes) on different servers.

In version 3.12.6 we were using ILock and as per migration guideline for 4.0.1 we started using FencedLock.

But issue while using version 4.0.1, to enable CP subsystem requires at least 3 hazlecast nodes and in our application having 2 hazelcast node and in disable mode it not provide strong consistency guarantee.

We require strong consistency guarantee as we are using Lock for one of critical condition. We still have option to use Imap.Lock but Imap not provides method which provided by FencedLock like isLockedByCurentThread() etc.

 

So could you please suggest possible solution on above issue?

Thanks & Regards

Yogesh 

[Yogesh Sonune]

Hi Mehmet, 

Thanks for reply.

As per above reply we made changes from ILock to FencedLock while upgrading from 3.12.6 to 4.0.1

After upgrading 4.0.1, noticed that when one node which holding FencedLock is shutdown then other node which waiting for FencedLock taking average 2-3 min to acquire lock which was not case while using ILock in version 3.12.6.

Can you confirm it is due to as we are using non-CP FencedLock mode but as I mentioned above it was not case with ILock in version 3.12.6.

Could you please help to suggest solution on above issue.

Thanks and Regards

Yogesh Sonune

[Mehmet Dogan]

There was an issue which prevented close of the sessions while a node is shutting down in unsafe (non-CP) mode. So sessions remained open until timeout. This was fixed in 4.0.2. Most probably what you observed is this issue.

See https://github.com/hazelcast/hazelcast/issues/17168 

- Mehmet Dogan -

To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/33037e2d-dad8-48c1-bb3b-8525919719dbn%40googlegroups.com.