registry communication is not valid for v3.

[Shobhajayanna]

Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

Linked to # (issue)
Part of the # (epic)

Type of change

Please delete options that are not relevant.

• fix: Bug fix (non-breaking change which fixes an issue)
• feat: New feature (non-breaking change which adds functionality)
• docs: Change in a documentation
• refactor: Refactor the code
• chore: Chore, repository cleanup, updates the dependencies.
• BREAKING CHANGE or !: Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the style guidelines of this project
• PR title conforms to commit message guideline ## Commit Message Structure Guideline
• I have commented my code, particularly in hard-to-understand areas. In JS I did provide JSDoc
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• The java tests in the area I was working on leverage @nested annotations
• Any dependent changes have been merged and published in downstream modules

For more details about how should the code look like read the Contributing guideline

[arxioly]

Why this document is not valid for V3? I mean, these two sub-articles, yes:
Gateway & ZuulHandlerMapping
Ribbon load balancer
But everything else I think is still valid. Maybe only this sub-article also needs to be refactored a bit:
Gateway & Discovery Client

[Shobhajayanna]

Why this document is not valid for V3? I mean, these two sub-articles, yes: Gateway & ZuulHandlerMapping Ribbon load balancer But everything else I think is still valid. Maybe only this sub-article also needs to be refactored a bit: Gateway & Discovery Client

this kind of implementation of registration and communication is removed in v3. its refreshened automatically after every 30secs.

[arxioly]

Why this document is not valid for V3? I mean, these two sub-articles, yes: Gateway & ZuulHandlerMapping Ribbon load balancer But everything else I think is still valid. Maybe only this sub-article also needs to be refactored a bit: Gateway & Discovery Client

this kind of implementation of registration and communication is removed in v3. its refreshened automatically after every 30secs.

No, it's still the same. Registration mechanism wasn't changed, and refreshing every 30s was always there. What is changed is that Ribon and Zuul were removed, it means authentication and routing is changed. But Discovery is the same. This document needs to be refactored, but not removed, unless it's duplicating information from Zowe Docs.

[pj892031]

Why this document is not valid for V3? I mean, these two sub-articles, yes: Gateway & ZuulHandlerMapping Ribbon load balancer But everything else I think is still valid. Maybe only this sub-article also needs to be refactored a bit: Gateway & Discovery Client

this kind of implementation of registration and communication is removed in v3. its refreshened automatically after every 30secs.

No, it's still the same. Registration mechanism wasn't changed, and refreshing every 30s was always there. What is changed is that Ribon and Zuul were removed, it means authentication and routing is changed. But Discovery is the same. This document needs to be refactored, but not removed, unless it's duplicating information from Zowe Docs.

For me as the author, it is pretty pitty to remove it, but it is really for v1 and v2. The purpose of this document was to describe the improvements in the Eureka / ZUUL to shortcut delays between onboarding/instance updates and routing itself. But the majority of that disappeared:

• gateway is not notified (bean gatewayNotifier was removed)
• the routing is not handled, it is on the level of WebFlux
• there are no authentication scheme commands (replaced by filters)
• RouteLocator is regenerating all rules every 30 seconds (again without any influence)
• actually, there is no improvement now from the default behavior

I guess to make this document sense for v3 we should reimplement such improvements as we did in v1 and this is not our aim for now. Therefore I assume it is better to remove it because it is more misleading than helpful and we can always take a look at previous branches (v1.x.x and v2.x.x.).

We can potentially create an issue to implement a similar approach:

• once a service update registry in the Discovery service
  • the Eureka caches could be cleaned
  • the Gateways could be notified (reverting of GatewayNotifier)
• once Gateway is notified, a gateway could call applicationEventPublisher.publishEvent(new RefreshRoutesEvent("List of services changed")); to regenerate routing issue

Anyway, I assume it should be consulted by the whole team and it is something that is not necessary to be implemented in this initiative of Spring Cloud Gateway. The potential benefit is just short time on the startup - mainly for testing purposes.

[arxioly]

Ok then, as a compromise create an issue, please. Otherwise we will forget about it for sure.

[Shobhajayanna]

Ok then, as a compromise create an issue, please. Otherwise we will forget about it for sure.

issue created to have it in the backlog
#3621