4

I am updating to latest Hazelcast version [3.12] and I am facing problem to obtain a instance of AtomicLong. The new version, HZ introduces the concept of CAP Theorem, to grant Consistency and Partition Tolerance, but he problem is the CP subsystem must have at least 3 members.

Config config = new Config();
config.getCPSubsystemConfig().setCPMemberCount(3);
config.getCPSubsystemConfig().setGroupSize(3);

HazelcastInstance instance1 = Hazelcast.newHazelcastInstance(config);

How can I configure the CP Subsystem to provides me an instance of atomicLong with just two hazelcast nodes?

If I start my application with just one node, the follow message is printed:

MetadataRaftGroupManager.log:65 [127.0.0.1]:6000 [dev] [3.12] CP Subsystem is waiting for 3 members to join the cluster. Current member count: 1

I will have just two nodes, so, the CP Subsystem doesn't allow me to use an atomicLong because it will waits for ever for at leats 3 nodes..

The version 3.11 I just called hazelcast.getAtomicLong("count"). How can I handle with this?

Renato Rodrigues
  • 53
  • 4

1 Answers1

3

In 3.12, The CP subsystem cannot be configured to operate with fewer than 3 nodes, because this would sacrifice the "consistency" which is the entire purpose of the CP subsystem under some failure scenarios (network partitioning). [EDIT: See new comment below regarding 4.0 and later behavior]

You can still use the 3.11 APIs, so the code you have from your 3.11 implementation will continue to work. Although the 3.11 APIs are marked deprecated, they are not removed or disabled; the deprecation is a warning that the APIs are known to be vulnerable to consistency issues in a split brain scenario. Some application code is tolerant of such issues and the vulnerability isn't a concern; if your application is not tolerant of a potential consistency issue with the atomic long then adding an additional node in order to migrate to the CP implementation will be required.

Mike Yawn
  • 796
  • 3
  • 8
  • Hi Mike, Thanks for aswering. I am not sure if is the best way force at least tree nodes for application which depends on IAtomicLong, IAtomicReference , FencedLock , ISemaphore and ICountDownLatch, provided by CP Subsystem.. Maybe the client of API should defines if it cares about consistency or not.. This new feature may unfeasible many application that doesn't run over many nodes.. By the way, the old implementation is deprecated and will be removed in 4.0 version. – Renato Rodrigues May 02 '19 at 19:35
  • Tough I understand why you deprecate the old APIs and migrate to CP implementation, however this causes some issues. For example the whole application is no longer working, if for some reason one of the 3 required nodes go down. If you only have 3 nodes, this can happen for many reason, like server failure, maintenance, etc. While only 2 nodes available, the application cannot use Locks, Atomic Longs, etc. which is not always good. I suggest to keep and don't remove the old approach also beside the CP subsystem, then devs can decide which to use... – user1536873 Oct 11 '19 at 07:54
  • In the 4.0 release, there will be a modification to the CP subsystem to support operating in unsafe mode. For many users, consistency is a hard requirement - it would be better to be unavailable than to return incorrect results. That is situation that CP subsystem is designed for. With the new unsafe mode, you can prefer availability, and allow the APIs such as FencedLock to continue to operate even when a full CP quorum is not present. – Mike Yawn Oct 21 '19 at 17:56