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
The blackListedServiceInstances in SpringCloudCommandRouter should be reevaluated from time to time #6
Comments
Fair suggestion @dhermanns and definitely something we've been thinking about. What was your suggested plan of attack to reevaluate the black-listed |
Simplest way - and that is how I implemented it so far, is adding the possibility to disable blacklisting using the SpringCloudCommandRouter.Builder. |
Some setting through the builder indeed makes a lot of sense. I however thought along the lines of reevaluating like stated in the title. So, maybe a two fold setting, (1) specifying the interval and (2) the operation to perform in regards to reevaluating. Regardless, disabling altogether is also a feature request of course. What do you think @dhermanns? Would you prefer a feature to disable black listing entirely? |
Disabling Blacklisting would be enough in our use case. I will prepare a PR
for that if it fits for you.
|
Ah, didn't mean to close this issue just yet, sorry for that.. However, it might come to that in a couple. The current implementation will black list a The alternative solution I suggested just now in #8, which will likely come down to configuring a The defaulted functions would, for both the What do you think @dhermanns, would that work? |
Sounds great! I think that should help in both use cases I have raised. |
Great! Then I think we should be able to move forward with this issue under the description I've provided. |
- Store the entire ServiceInstance instead of just the identifier. Doing so will uncover reuse of id's, with different host/port combinations - To match ServiceInstances, reuse the custom equals method which was present in the SpringCloudCommandRouter. Doing so ensure we cover for scenarios where the ServiceInstance does not implement equals - Clean up the javadoc accordingly - Remove the cleanIgnoredInstanceSet operation. Any conceivable solutions in this space reflect the intent of issue #6. To not pull in that issue too, that logic should be removed to that issue for a following release. Furthermore, the old approach of clean up, which based itself on the entire set of discoverable ServiceInstances no longer works, as we fetch capabilities per instances, not all of them at once #1647
I've adjusted the priority and changed the milestone of this issue. For the time being, I think this issue will require us to adjust the As #23 has been introduced into release 4.4, I think it only fair to start working on this issue for milestone 4.5. |
The IgnoreListingDiscoveryMode should let ignored ServiceInstances expire after some time. This expiry time should be configurable to allow users to choose when to evict entries. #6
Adjust coverage run approach for the pull request task #6
Adjust the threshold from long to Duration #6
It looks to me like a once blacklisted service will stay blacklisted. It will be removed in class
SpringCloudCommandRouter
here:only, if the serviceInstance isn't discovered anymore at all.
This could be problematic, if you are using the
SpringCloudHttpBackupCommandRouter
.It blacklists a service just because the method:
failed. This could be the case during the bootup phase: Consul already discovers the service, but the HTTP Endpoint isn't reachable. In our case, the service was blacklisted for all times as a result.
Suggestion: Reevaluate the blacklisted services from time to time. That would work around the race condition during service startup. If you like, I could add a solution to my already existing PR #4.
The text was updated successfully, but these errors were encountered: