-
Notifications
You must be signed in to change notification settings - Fork 15
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
DiscoveryClient API comments #19
Comments
Those were mostly exposed as helper methods to access ZK. Since I initially created this module, I've never actually used it in production, so if there are improvements or cleanups we can make, I'd be all for that. |
@jplock So how is the DiscoveryClient supposed to be used by the services? If so, I believe that is would be useful to create a client that does this discovery (and possible retries) under the hood and provide a fluent interface (something like https://github.com/Netflix/ribbon). |
@aantoniadis I used Ribbon in my |
@jplock any plans to merge |
@aantoniadis probably not |
@jplock Just want to ensure I understand the above comment correctly.... |
This library will register a service with ZK and includes a client to get a host and port from ZK if you want to talk to another service. This library doesn’t include a load balancer implementation like dropwizard-consul does. |
This DiscoveryClient is the client that I can use to get host/port from ZK, right? |
@sliu2013 correct |
I have been using the library recently and I have a couple of comments regarding the API
that might worth taken into consideration.
io.dropwizard.discovery.client.DiscoveryClient
exposes the following methodsMy comment is that it is not intuitive whether a call on a method will return results from the cache or not. Maybe if we used different names for each case it would make the intention of each method much clearer.
Also, since the DiscoveryClient client is create by
DiscoveryClient.newDiscoveryClient
where the serviceName is passed. Why would somebody callDiscoveryClient#Collection<ServiceInstance<T>> getInstances(@Nonnull final String serviceName)
?From the factory API, I would expect the discoveryClient to find 1 type of service.
@jplock what do you think?
The text was updated successfully, but these errors were encountered: