Bug Fix : When the Collection of Services is empty the monitor should gracefully return #27
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.
The ServiceFinderHub updateRegistry has the following problem...
When we use a dynamic dataSource, http or zk, and when there are call failures - and the dynamicDataSources returns a list of empty services, in the above case newFinders will be empty and matchingServices.size will never match with the knownServiceFinders.size, thereby resetting the entire serviceFinders. Hence the serviceFinders end up returning empty data in case of an outage.
The fix is to gracefully ignore the empty service list and to retain the older service list.
P.S: There is another way of tackling as well. Change the contract of the ServiceDataSource to an optional collection (informing the ones extending that it could be empty) and instead of doing an isEmpty check here, do a null check instead
Or, throw an exception from the service data sources and let the exception handling path take care of it in case of exceptions instead of doing the emptyList and checking on it. With this, true emptyLists will be preserved. But an emptyList from a service dataSource is rare and usually because of something else going on, imo! So preserving the finders in that case made more sense. (Also it isn’t styled like this in other data sinks and sources)
Can do either anyway depending on how you want it styled.