Hi, Well, *if* we want to check the system state, that check should be done continuously during the whole lifetime otherwise it makes no sense, honestly:
The goal is to not stop the system, so a system startup is a seldom case and bruning cycles for a case, which almost never (in theory and as a goal) happens, sounds not very productive.... Regards Felix Alexander Klimetschek schrieb: > On Tue, Jun 16, 2009 at 7:55 AM, Felix Meschberger<[email protected]> wrote: >>> Isn't it possible to avoid that case with start levels? (we are >>> talking about the initial startup only, if the configadmin goes away >>> later, no problem, the system ready state should IMHO never switch >>> from true to false as it is only for the startup) >> This is of course wrong. *If* we have a system status service, this is >> used throughout the lifetime of the system. That is it may happen that >> the system becomes unavailable if something is going away. >> >> Just to have a status mechanism for startup makes no sense. > > Well, the whole point of the system ready detection is to find out at > what point in time everything is up and running to serve requests (and > not send a 503 Service Unavailable) after a startup. With "legacy" > frameworks such as the old Spring, where components were hardwired, > startup was deterministic and quite easily to detect. Now within the > context of a highly asynchronous system we need a separate solution. > > But I don't think that bundles going away or crashing during the > lifetime should lead to a 503 immediately. They might indicate a > problem and one wants to see this problem rather than a 503. Or the > system ready config has to be changed alongside a major redeployment > took place and you don't want to restart the system (considering the > config is stored in the sling.properties that are only read on > restart). If we don't get this right, you see a 503 way too often also > things might be running perfectly. > > Regards, > Alex >
