How to set an attribute for my local member in Hazelcast 4.1

440 views
Skip to first unread message

anil kumar

unread,
Dec 15, 2020, 11:31:48 AM12/15/20
to Hazelcast
Hi, 
I'm trying to upgrade Hazelcast in my application from 3.12 to 4.1 version
In 3.12, I used to set an attribute to Hazelcast Member by using member.setStringAttribute(key, value)
I'm trying to do the same in 4.1, but not able to find a corresponding alternative.
I've tried using member.getAttributes().put(key, value). This has failed with UnsupportedOperationException as getAttributes is returning a unmoidifable collection
I've also tried using ((MemberImpl)member).setAttribute(key, value). This has failed with 'java.lang.UnsupportedOperationException: Attributes can not be changed after instance has started'

Can you please let me know if there is a way to set an attribute for my local member?

Thanks,
Anil

Ahmet Mircik

unread,
Dec 15, 2020, 1:36:34 PM12/15/20
to Hazelcast

Hi Anil,
In order to prevent changes after instance start, it was removed in 4.0.
What was the use case you are trying to address?


--
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/344bfa79-e167-441a-9d35-d6529ff233d5n%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

anil kumar

unread,
Feb 4, 2021, 2:01:30 AM2/4/21
to Hazelcast
Hi Ahmet,

Apologies for the delayed response. 

Here is the usecase. When split brain happens and a node moves out of cluster; and subsequently when it recovers and joins the cluster back, we have seen cases where localMember's name is not set (null) and its uuid changes. To address such cases, we try to set a unique id as localmember's name and internally maintain a map of member's uuid to unique id (localmember's name) 

Since the ability to set an attribute to Member after instance start is removed in HZ4, can we assume that in such split brain scenarios, the member that rejoins the cluster will have the same localmember information (uuid and name) as earlier ?


Thanks,
Anil Kumar N

anil kumar

unread,
Feb 4, 2021, 11:16:12 AM2/4/21
to haze...@googlegroups.com
Can you please provide your inputs?

Thanks,
Anil Kumar N

You received this message because you are subscribed to a topic in the Google Groups "Hazelcast" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hazelcast/w3c5jcYFkM4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hazelcast+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/58136af0-79a8-44f6-8261-29ceb4038d48n%40googlegroups.com.

anil kumar

unread,
Feb 6, 2021, 12:55:47 AM2/6/21
to Hazelcast
Can anyone please answer this?

Joe Sherwin

unread,
Feb 6, 2021, 1:28:48 AM2/6/21
to haze...@googlegroups.com
Anil, please give some us more context to your use-case which required dynamically adding attributes to members? Also, which attributes are you attempting to apply after instance creation? This way we can suggest alternatives.

On Feb 6, 2021, at 12:55 AM, anil kumar <nani...@gmail.com> wrote:

Can anyone please answer this?

Joe Sherwin

unread,
Feb 6, 2021, 1:42:26 AM2/6/21
to haze...@googlegroups.com



On Feb 6, 2021, at 12:55 AM, anil kumar <nani...@gmail.com> wrote:

Can anyone please answer this?

anil kumar

unread,
Feb 6, 2021, 3:14:07 AM2/6/21
to Hazelcast
On startup of the hazelcast instance, we set local_member_name using config.setProperty("local_member_name", "uniqueid").

When split brain happens and when the node rejoins the cluster after that, we have noticed that the node's UUID changes and the local_member_name attribute is missing on the hazelcast instance; and we try to set it in Hazelcast 3.x using hazelcastInstance.getCluster().getLocalMember().setStringAttribute("local_member_name", "uniqueid")

This info is needed for us as we internally maintain a cache of UUID and Member (to track the active cluster members), and try to update the cache with the correct UUID and member's info (local_member_name) when the node rejoins.

Now, in Hazelcast 4.x, noticed that we cannot set the attribute using hazelcastInstance.getCluster().getLocalMember().setStringAttribute("local_member_name", "uniqueid").

we would like to know if there is any workaround for this, or can we assume that, when the node rejoins after split brain scenario, UUID/local member's info will not change?
Please provide your inputs and let us know if any other details are needed.


Thanks,
Anil Kumar N

Joe Sherwin

unread,
Feb 6, 2021, 12:18:16 PM2/6/21
to haze...@googlegroups.com
Consider using our Membership Listener for this...
https://docs.hazelcast.com/imdg/4.1.1/events/cluster-events.html#listening-for-member-events

Additionally, if split brian situations are a concern, have a look at our split-brain protection and CP subsystem configurations...


On Feb 6, 2021, at 3:14 AM, anil kumar <nani...@gmail.com> wrote:

On startup of the hazelcast instance, we set local_member_name using config.setProperty("local_member_name", "uniqueid").

Joe Sherwin

unread,
Feb 17, 2021, 8:36:25 AM2/17/21
to haze...@googlegroups.com
How to pragmatically set member attributes 
MemberAttributeConfig memberAttributes = new MemberAttributeConfig(); memberAttributes.setStringAttribute("hostname", "host1"); memberAttributes.setStringAttribute("name", "1"); Config config = new Config(); config.setMemberAttributeConfig(memberAttributes);
HazelcastInstance instance = Hazelcast.newHazelcastInstance(config); Set<Member> members = instance.getCluster().getMembers(); for (Member member : members){ System.out.println(member.getStringAttribute("name")); 
} 



On Feb 6, 2021, at 3:14 AM, anil kumar <nani...@gmail.com> wrote:

On startup of the hazelcast instance, we set local_member_name using config.setProperty("local_member_name", "uniqueid").

Nitin Singh

unread,
Aug 5, 2021, 2:45:39 AM8/5/21
to Hazelcast

I hope this is not going as duplicate reply from me earlier. Some trouble posting. Anyway,

We have a new use case around setting attributes on members during runtime and is proving to be quite a blocker for 3.12 to 4.x upgrade ! Please suggest some viable workaround.

Use Case :

We have multiple wars on (multiple) tomcat, each war deployment starts its own hazelcast instance.

On first time start up of specific war type (say master), we would like to read one time config and other settings from database and push it into (global) hazelcast cache visible to all nodes on cluster. We achieve this by making use of ability to set runtime attributes on nodes.

Specifically , say master-a and master-b start, we check if attribute has already been set by one of master node. If not, current node acting as one time initializer loads stuff from database, and sets some runtime attribute to signal completion of init phase. Other master node starts, joins cluster, and skips (re)loading from database and just consumes info already pushed into hazelcast map.

All other non-master nodes wait until at least one of master has set above attribute !

Thanks,
Nitin

Bence Eros

unread,
Aug 5, 2021, 4:01:57 AM8/5/21
to haze...@googlegroups.com
Hello,

I suggest using an IMap instead of a cache, and configuring a MapLoader for the map that reads the configuration from the database on startup: https://docs.hazelcast.com/imdg/4.2/data-structures/map.html#initializing-map-on-startup

On the non-master nodes, you can simply omit the maploader configuration.

Kind regards,



--
Bence Erős

dev@management-center

er...@hazelcast.com

Hazelcast

2 W 5th Ave, Ste 300 | San Mateo, CA 94402 | USA

+1 (650) 521-5453 | hazelcast.com

Poornima Baddi

unread,
Jan 16, 2023, 4:08:50 PM1/16/23
to Hazelcast
Hi,

Would share like to share the input on this. What fix is required for this?

Regards,
Poornima

Joe Sherwin

unread,
Jan 17, 2023, 6:36:12 AM1/17/23
to haze...@googlegroups.com
Poornima, I have questions about this solution. If you're updating an ICache or IMap with this member name & uuid info during a rejoin after a split brain event, which split brain merge policy are you using? Which type of listener are  you using to detect members going in and out the cluster, Lifecycle, membership, or quorum? Meanwhile, here's some alternatives...

public class NodeLifecycleListener implements LifecycleListener, HazelcastInstanceAware{  private transient HazelcastInstance hz;

@Override public void stateChanged(LifecycleEvent event) {
if(event.equals(LifecycleEvent.LifeCycle.STARTED) ||
event.equals(LifecycleEvent.LifeCycle.MERGED)){
IMap<String, String> membersTrakingMap = hz.getMap("membersTrakingMap");
membersTrackingMap.put(hz.getConfig().getInstanceName(),
hz.getCluster().getLocalMember().getUuid().toString());
} System.err.println(event); }

@Override public void setHazelcastInstance(HazelcastInstance hz) {
this.hz = hz;
}
}

Make sure to register in config to not miss any startup events...

<hazelcast>
...
<instance-name>${HZ_MEMBER_NAME}</instance-name> <listeners> <listener> com.yourpackage.NodeLifecycleListener </listener> </listeners>
<map name="memberTrackingMap"> <merge-policy batch-size="100">DiscardMergePolicy</merge-policy> </map> ... </hazelcast>

Also, see checking uuid & instance name using REST endpoints.

On Jan 16, 2023, at 4:08 PM, Poornima Baddi <pba...@gmail.com> wrote:

Hi,
Reply all
Reply to author
Forward
0 new messages