During reconnections, the client would normally try to connect to the last known member list, and then try the configured member addresses.
This logic is fine for most of the use cases, but for some users who expose their multi-member clusters via a single load balancer or node port, this might not be what we want. In their use cases, cluster members are not accessible from the client directly, the connection has to be established by the service in front of the cluster members.
For such scenarios, not trying to connect to the members from the last known member list is probably what we want.
We decided not to change the default behavior, or be smart and try to detect such cases. Instead, we decided to introduce a private property for now, and share that with the customer that wants this feature. In the future, depending on the feedback and our own discussions, we might promote this to a public property as well.
The tracking issue for the Java side PR.
See https://github.com/hazelcast/hazelcast/pull/24772 for details.
During reconnections, the client would normally try to connect to the last known member list, and then try the configured member addresses.
This logic is fine for most of the use cases, but for some users who expose their multi-member clusters via a single load balancer or node port, this might not be what we want. In their use cases, cluster members are not accessible from the client directly, the connection has to be established by the service in front of the cluster members.
For such scenarios, not trying to connect to the members from the last known member list is probably what we want.
We decided not to change the default behavior, or be smart and try to detect such cases. Instead, we decided to introduce a private property for now, and share that with the customer that wants this feature. In the future, depending on the feedback and our own discussions, we might promote this to a public property as well.