You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When cluster id changed we were resetting member list
with an empty memberlist. It turned out that there are implementations
that assumes it will never be empty.
Instead of clearing the memberlist on cluster id change, we
are keeping the cluster id as part of the latest snapshot
to be able to fire correct events. In other words, on cluster restart
we need to fire removed events for all old members and added
events for all new members coming from restarted cluster.
We were achieving this via clearing memberlist and firing removed
events first. Then after some time new memberlist comes and we fire
added events. And the memberlist is empty during this period.
To prevent that, we have changed the logic. Now clusterUuid is
part of the logic. We don't clear the memberlist at all. Upon receiving,
an event, we compare existing and new clusterUuid. If they are different,
without comparing the members, we fire removed events for all existing
members, and added events for all new ones to achieve same behaviour.
Note that clearing memberlist on cluster id change was
introduced as a fix to hazelcast/hazelcast#18245
So it is important not to break related ClientHotRestartTest
The tracking issue for the Java side PR.
See hazelcast/hazelcast#20818 for details.
When cluster id changed we were resetting member list
with an empty memberlist. It turned out that there are implementations
that assumes it will never be empty.
Following test failure is an example of it.
hazelcast/hazelcast#20264
Instead of clearing the memberlist on cluster id change, we
are keeping the cluster id as part of the latest snapshot
to be able to fire correct events. In other words, on cluster restart
we need to fire removed events for all old members and added
events for all new members coming from restarted cluster.
We were achieving this via clearing memberlist and firing removed
events first. Then after some time new memberlist comes and we fire
added events. And the memberlist is empty during this period.
To prevent that, we have changed the logic. Now
clusterUuid
ispart of the logic. We don't clear the memberlist at all. Upon receiving,
an event, we compare existing and new clusterUuid. If they are different,
without comparing the members, we fire removed events for all existing
members, and added events for all new ones to achieve same behaviour.
Note that clearing memberlist on cluster id change was
introduced as a fix to hazelcast/hazelcast#18245
So it is important not to break related ClientHotRestartTest
fixes hazelcast/hazelcast#20264
Checklist:
Team:
,Type:
,Source:
,Module:
) and Milestone setAdd to Release Notes
orNot Release Notes content
set@Nonnull/@Nullable
annotations@since
tags in JavadocThe text was updated successfully, but these errors were encountered: