stefan-egli commented on PR #12:
URL:
https://github.com/apache/sling-org-apache-sling-discovery-base/pull/12#issuecomment-2810011169
IIUC then this is intended for health during startup - given the description
mentions "until the system is in a stable state" or "until the system is ready".
Also I'm assuming the model where the rest of the local cluster treats the
starting-up instance as already part of the cluster - while the starting-up
instance itself wants to wait with topology initialization until readiness is
signaled.
So that makes the logic somewhat more involved : things should work normally
wrt discovery for everybody else, just for the local instance it is delayed.
For example: one problem that comes to mind as a result of this is : the
JoinerDelay. That ensures that an instance that is already announcing itself
through oak leases - but has not yet set all its sling-level infos - is
suppressed (delayed), until it finishes its initialization completely. So this
new feature here must work well with JoinerDelay, I guess is what I'm trying to
say.
At the current state of this draft however, the BaseDiscoveryService is
returning the {{oldView}} in case of not-yet-ready. That would be problematic,
as that would mean it is not taking part of the JoinerDelay logic. Which would
mean other cluster members could get delayed with establishing a topology.
I think the way the integration with JoinerDelay is going to look like is a
major aspect of how this should be designed.
Other than that, I think BaseDiscoveryService shouldn't have to worry about
TopologyEventListeners, and as such also not have manage that list in
topologyEventListeners. That aspect is handled by the ViewStateManagerImpl.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
