Enabled ClientStateListener to be used on FailoverClient #19090
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Due to nature of how failover client works, we don't allow different listeners to be registered at different client configs. Since ClientStateListener registers itself to the ClientConfig, this prevents it to be used via FailoverClient. The reasoning behind constructor register itself is to force the user to use this via config rather than registering it after client starts. So, sticking with the same decision we introduce another constructor which accepts ClientFailoverConfig and registers same listener(itself) to all the client configs. Also on the ClientStateListener I have ignored `CLIENT_CHANGED_CLUSTER`. This is rather a temporal event. We fire CLIENT_CONNECTED than CLIENT_CHANGED_CLUSTER, in those cases we want the current state to remain CLIENT_CONNECTED. fixes hazelcast#18351
sancar
added
Type: Defect
Team: Client
Source: Internal
This was referenced Jul 14, 2021
srknzl
approved these changes
Jul 14, 2021
| public ClientStateListener(@Nonnull ClientFailoverConfig clientFailoverConfig) { | ||
| List<ClientConfig> clientConfigs = clientFailoverConfig.getClientConfigs(); | ||
| for (ClientConfig clientConfig : clientConfigs) { | ||
| clientConfig.addListenerConfig(new ListenerConfig(this)); |
There was a problem hiding this comment.
asking to be sure, I think the problem is resolved since the listeners registered to each config is the same object here, isn't it?
| for (ClientConfig clientConfig : clientConfigs) { | ||
| clientConfig.addListenerConfig(new ListenerConfig(this)); | ||
| } | ||
|
|
mdumandag
reviewed
Jul 14, 2021
hazelcast/src/main/java/com/hazelcast/client/util/ClientStateListener.java
Outdated
Show resolved
Hide resolved
hazelcast/src/main/java/com/hazelcast/client/util/ClientStateListener.java
Outdated
Show resolved
Hide resolved
mdumandag
approved these changes
Jul 16, 2021
This was referenced Jul 16, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Due to nature of how failover client works, we don't allow different
listeners to be registered at different client configs.
Since ClientStateListener registers itself to the ClientConfig,
this prevents it to be used via FailoverClient.
The reasoning behind constructor register itself is to force the
user to use this via config rather than registering it after client
starts.
So, sticking with the same decision we introduce another constructor
which accepts ClientFailoverConfig and registers same listener(itself)
to all the client configs.
Also on the ClientStateListener I have ignored
CLIENT_CHANGED_CLUSTER.This is rather a temporal event. We fire CLIENT_CONNECTED than
CLIENT_CHANGED_CLUSTER, in those cases we want the current state to
remain CLIENT_CONNECTED.
Fixes #18351
EE PR: https://github.com/hazelcast/hazelcast-enterprise/pull/4142
Checklist:
Team:,Type:,Source:,Module:) and Milestone setAdd to Release Noteslabel if changes should be mentioned in release notes orNot Release Notes contentif changes are not relevant for release notes@Nonnull/@Nullableannotations@sincetags in Javadoc