stefan-egli commented on PR #12:
URL: 
https://github.com/apache/sling-org-apache-sling-discovery-base/pull/12#issuecomment-2812673383

   The reason I asked is that the interplay between `bindSystemReadyService`, 
`unbindSystemReadyService`, `activate` and `deactivate` with how they set the 
"readiness state" is not clear to me. Essentially I don't think the way it is 
done now works as intended. For example `unbindSystemReadyService` assumes 
`deactivate` is called before - but that's not how I understood this works. 
`unbindSystemReadyService` I assume is called as soon as the system is no 
longer ready. but that can be a long time before actual `deactivate` is called. 
(similar with `bindSystemReadyService` where it only calls 
`setSystemReady(true)` in a very specific case, not covering all possibilities).
   
   * It seems the main introduced hook here is `shouldDelayTopologyChange` 
which is invoked in `getTopology`. This seems appropriate for startup (as the 
"delay" aspect is from detached to being attached). For shutdown I fail to see 
how this would have any effect. At the current state of the draft shutdown 
doesn't seem covered - I think what it should do is cause a TOPOLOGY_CHANGING 
and stay there (but I don't see that happening from the current code - it 
should invoke `oldView.setNotCurrent()` somewhere...).
   
   * In that context : `TopologyDelayHandler` doesn't seem to capture well what 
the class should be used for. I think it's not so much about delay but about 
system readiness.
   
   * IIUC then the idea of `startupTimeout` is to "force mark the instance as 
ready" after the timeout. That is a bit unexpected from the naming - perhaps 
having that explicitly described in some comment would be good. But besides 
that : do we want this?
   
   * I think the `startupInProgress`, `systemReady` and `shutdownInProgress` 
being 3 different AtomicBooleans is making the code somewhat complex. It might 
be easier to track one state - as the state transitions are then easier to 
catch.
   
   * How should it behave when `startupTimeout==0` : it seems it sets 
`startupInProgress.set(false)`, but then nothing further ever happens. It will 
never set `systemReady` to `true`. Which is unexpected.
   
   * What I'm also wondering is : should `systemReadyService==null` be 
supported. It seems the `systemReadyService` is essential to 
`TopologyDelayHandler` and the way it is implemented now it seems to bypass it 
in certain cases. Which I'm not sure helps...
   
   * The `SystemReadyService` would probably be good to extend, as it is 
currently only an interface that leaves out a few questions: for example : what 
is the idea of `isSystemReady`, when is that true, when false. Isn't the idea 
of the `SystemReadyService` that is is only registered when the system is ready 
(how else would depending services be able to know when `isSystemReady` 
switches between false and true. I think it doesn't need a `isSystemReady`.


-- 
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

Reply via email to