-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Implement tests for EurekaReactiveDiscoveryClient and EurekaDiscoveryClientTests #4508
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| } | ||
|
|
||
| @Override | ||
| public void probe() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default implementation already calls getServices() which calls this.eurekaClient.getApplications() so how is this doing anything different?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey Ryan, thanks for reviewing :)
As per the Discovery client interface, where the probe() function is defined, the Javadocs mention there’s an intention for it to be a lightweight probe to ensure connectivity.
The major difference here is that calling this.eurekaClient.getApplications() directly avoids the overhead from getServices(), which iterates over all registered applications, allocates new lists, and lowercases each name. The goal was to keep probe() minimal and avoid unnecessary allocations when we don’t need the data being returned.
Do you prefer keeping it to getServices()?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree getServices() does do some additional work, but most of the overhead is incurred by the network request of the getApplications() call itself so I dont see this saving a ton of overhead unless you had a very large number of instances.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense, this might be a premature/uneeded optimization. I am fine with reverting the override, and keeping the default implementation.
What do you think would be a fitting way to move forward?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need to do anything because it should already be using the default implementation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The override is now reverted as discussed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess I dont understand why we need to make any changes in spring-cloud-netflix if the default implementations in spring-cloud-commons is acceptable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies, I seem to have misunderstood the intention :)
Do you think the tests would still add any value, or should I go ahead and close the PR? Thanks again for taking the time to review it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tests are fine but the reactive implementation is still overriding the default implementation
Signed-off-by: Mohamed Macow <mmacovv@gmail.com>
Signed-off-by: Mohamed Macow <mmacovv@gmail.com>
Signed-off-by: Mohamed Macow <mmacovv@gmail.com>
Signed-off-by: Mohamed Macow <mmacovv@gmail.com>
Signed-off-by: Mohamed Macow <mmacovv@gmail.com>
Signed-off-by: Mohamed Macow <mmacovv@gmail.com>
Changes:
EurekaReactiveDiscoveryClientTests.EurekaDiscoveryClientTestsfocused on the default implementation for theprobe()method.See #4157 (comment)