Boundary for ServiceAddition and ServiceFinderHubRefresh #40
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
…ertaining to appform-io#22 b) Introduced hubStartDurationMs and finderRefreshDurationMs for defining the boundary. If this boundary were to breach, throw with an IllegalStateException c) Added tests, upgraded versions and added CHANGELOG
…dd a list of services without being blocked
koushikr
changed the title
santanusinha
approved these changes
Aug 13, 2024
ranger-core/src/main/java/io/appform/ranger/core/finderhub/ServiceFinderHub.java
Outdated
Show resolved
Hide resolved
ranger-core/src/main/java/io/appform/ranger/core/finderhub/ServiceFinderHubBuilder.java
Outdated
Show resolved
Hide resolved
…tants - the ones from RangerClientConstants to a single place
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.
This is pertaining to the dynamic service addition PR
What?
Dynamic Finder Construction via CompletableFuture (..) requires every client that interacts with ranger to implement the boundary within, and also solves only a part of the problem. The other half is, hubRefresh also needs to be similarly bounded.
Why?
If the clients don't handle the timeout on creation of a serviceFinder, by specifying a timeout on CompletableFuture provided - there is a risk that they will run into an infinite loop, since finder refresh will wait eternally. Same with the hub. In cases where the node_data_sources are unreachable or latent, this may manifest. This boundary condition exits that infinite loop. (This when a nodeDataSource is unreachable)
If the upstream a service is calling is down, it has no impact on the service coming up - it is not to be confused with that. The service will still come up with empty nodes for the stream. Please check the implementations of node_data_source refresh for both zk and http for the same.
How?
Introduced hubStartDurationMs and finderRefreshDurationMs for defining the boundary, in the hubBuilder. If this boundary were to breach, throw with an IllegalStateException.
Added tests, upgraded versions and updated CHANGELOG.
Also, this PR may not be required anymore.