You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Georg Henzler <sl...@ghenzler.de> on 2019/04/11 22:47:23 UTC
Creating a configuration during startup (was Re: [DISCUSS]
Consolidate starter-startup and startupfilter/startupfilter-disabler to use
Apache Felix HC ServiceUnavailableFilter)
Hi all,
I'm trying to add a config to the provisioning model [1] that is active
during first startup at startlevel 5. Looking at [2] this does not seem
to be possible (or it's not documented). On second startup it's fine
since the config is there, but on first startup, the config is only
created at startlevel 30 (there is a log for "CM Event Dispatcher" that
shows this). Moving the config to boot.txt also does not work. Not sure
why the configs are only made active that late on first startup,
configadmin would be available from startlevel 1 and from second start
on the configs are available early anyway...
Ideas?
Regards
Georg
[1]
https://github.com/apache/sling-org-apache-sling-starter/blob/master/src/main/provisioning/healthcheck.txt
[2]
https://sling.apache.org/documentation/development/slingstart.html#configurations
[3]
https://github.com/apache/sling-org-apache-sling-starter/blob/2791ff2442013cb8ce4fe8c7b74f35a4ad75fdd0/src/main/provisioning/boot.txt#L57
On 2019-04-08 10:49, Jörg Hoh wrote:
> Hi Georg,
>
> ok, wasn't aware of the "100% compatibility mode" :-) So +1 from my
> side.
>
> Jörg
>
> Am Mo., 8. Apr. 2019 um 00:28 Uhr schrieb Georg Henzler
> <ghenzler@apache.org
>> :
>
>> Hi Jörg,
>>
>> there is the option "autoDisableFilter" [1] in the
>> ServiceUnavailableFilter - if true the filter automatically
>> unregisters
>> itself upon first non-503 result. Once unregistered it listens to
>> FrameworkEvent.STARTLEVEL_CHANGED events to reregister once needed
>> (the
>> shutdown case). During normal operations (that includes deployments
>> that
>> might cause the selected "systemalive" checks to be temporarily
>> unavailable) the filter is not active (which is also good from a
>> performance perspective).
>>
>> So really, all that would be needed to replace oas-startupfilter +
>> -disabler and oas-starter-startup is the simple config [2] in the
>> oas-starter provisioning model.
>>
>> -Georg
>>
>> [1]
>>
>> https://github.com/apache/felix/blob/d5245ba3ba306b57b83c4d5c6cfe499d955b0acb/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/filter/ServiceUnavailableFilter.java#L98
>>
>> [2]
>>
>> org.apache.felix.hc.core.impl.filter.ServiceUnavailableFilter
>> tags=["systemalive]
>>
>> osgi.http.whiteboard.context.select="(&(osgi.http.whiteboard.context.name
>> \=*)(!(osgi.http.whiteboard.context.name\=org.osgi.service.http)))"
>> osgi.http.whiteboard.filter.regex=".*"
>> autoDisableFilter=B"true"
>>
>>
>> On 2019-04-07 19:49, Jörg Hoh wrote:
>> > Hi Georg,
>> >
>> > Merging the 2 implementations oas-startupfilter + -disabler and
>> > oas-starter-startup makes fully sense to me, although I am bit hesitant
>> > by
>> > replacing the basic approach.
>> >
>> > these 2 have a rather static assumption, when the application is up,
>> > and
>> > their sole purpose is to indicate that. And once the system is up, it's
>> > up
>> > and this state remains unchanged until the startupfilterDisabler is
>> > deactivated. A healthcheck based implementation can changed its mind
>> > based
>> > on many factors, you already mentioned the fact that key services
>> > should be
>> > available. If these services go down during runtime, the status of this
>> > check changes.
>> >
>> > If I understand you correctly, then the semantic of the startup itself
>> > might not change, but it's more likely, that the unavailability of such
>> > a
>> > key service would cause the Filter to kick again, changing
>> > runtime-behavior; currently it does not.
>> >
>> > Is this intended?
>> >
>> > Jörg
>> >
>> >
>> > Am Sa., 6. Apr. 2019 um 00:24 Uhr schrieb Georg Henzler
>> > <ghenzler@apache.org
>> >> :
>> >
>> >> Hi all,
>> >>
>> >> we have currently two mechanisms in Sling to wait for startup:
>> >>
>> >> * sling-org-apache-sling-startupfilter +
>> >> sling-org-apache-sling-startupfilter-disabler
>> >> * sling-org-apache-sling-starter-startup (only used for the starter
>> >> application AFAIK)
>> >>
>> >> Now that systemready in Felix is fully migrated to Felix Health Checks
>> >> I
>> >> would like to rely on ServiceUnavailableFilter [1] instead. The
>> >> advantage is that this filter can be configured in a declarative
>> >> fashion
>> >> (what is required to be alive can be configured, e.g. for a customer
>> >> project it's easy to wait for additional custom services) and 503 is
>> >> also correctly sent upon shutdown.
>> >>
>> >> Is this approach something everyone is ok with?
>> >>
>> >> -Georg
>> >>
>> >> [1]
>> >>
>> >>
>> https://github.com/apache/felix/blob/trunk/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/filter/ServiceUnavailableFilter.java
>> >>
>>
Re: Creating a configuration during startup (was Re: [DISCUSS]
Consolidate starter-startup and startupfilter/startupfilter-disabler to use
Apache Felix HC ServiceUnavailableFilter)
Posted by Robert Munteanu <ro...@apache.org>.
On Tue, 2019-04-16 at 08:19 +0200, Georg Henzler wrote:
> My proposal: We change the provisioning model in a way that all
> mentioned configurations become active exactly with the start level
> of
> org.apache.felix.configadmin. As this is the case from second startup
> on
> anyway, I suppose there is a very low risk of regressions (I created
> [2]
> for that.). The same probably has to be changed for the new feature
> model (I haven't looked into that yet).
+1
Robert
Re: Creating a configuration during startup (was Re: [DISCUSS]
Consolidate starter-startup and startupfilter/startupfilter-disabler to use
Apache Felix HC ServiceUnavailableFilter)
Posted by Georg Henzler <gh...@apache.org>.
Hi all,
so I have done some more testing and found out that during first
startup, it's not only the configs that become active very late:
1. Bundles of feature :boot become active at start level 1
2. All other bundles become active at start level 30 (and not what is
configured in provisioning files, the start level is set after
context.installBundle())
3. Fairly late of start level 30, the configurations become effective
My initial idea was to fix the collaboration of modules [1] to register
the configs correctly (osgiInstaller.registerResource() calls
ConfigTaskCreator eventually, in theory there is no reason why all this
should not be able to happen during start level 1 just after the
configadmin bundle becomes active, but in reality all the asynchronicity
in the bundle make it really hard).
So two questions:
To mitigate 3. from above:
Would it be an option to just set the configs in
sling-org-apache-sling-launchpad-base directly? (I think Bertrand this
is what you suggested, but if somehow possible I'd even prefer to do it
without listener but synchronously for robustness). This would also
imply that the configs get registered again in launchpad-installer and
then normally installed (again), but maybe this is not a problem?
To mitigate 2. from above:
What could we do to ensure the bundles get activated in declared order
(respecting startlevel)? (I found switchstartlevel [2] but somehow it
didn't work for me)
-Georg
[1]
https://github.com/apache/sling-org-apache-sling-launchpad-installer
https://github.com/apache/sling-org-apache-sling-installer-core
https://github.com/apache/sling-org-apache-sling-installer-factory-configuration
[2]
https://github.com/apache/sling-org-apache-sling-installer-core/blob/7b2e4407baa45b79d954dd20c53bb2077c3a5e49/src/main/java/org/apache/sling/installer/core/impl/OsgiInstallerImpl.java#L91
On 2019-04-16 08:44, Bertrand Delacretaz wrote:
> Hi,
>
> On Tue, Apr 16, 2019 at 8:19 AM Georg Henzler <gh...@apache.org>
> wrote:
>> ...My proposal: We change the provisioning model in a way that all
>> mentioned configurations become active exactly with the start level of
>> org.apache.felix.configadmin....
>
> Makes sense to me, I can't think of a good reason to activate configs
> at specific start levels.
>
> I suppose you just need a component that starts at level 1 and listens
> for the ConfigAdmin service availability to implement this.
>
> -Bertrand
Re: Creating a configuration during startup (was Re: [DISCUSS]
Consolidate starter-startup and startupfilter/startupfilter-disabler to use
Apache Felix HC ServiceUnavailableFilter)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Tue, Apr 16, 2019 at 8:19 AM Georg Henzler <gh...@apache.org> wrote:
> ...My proposal: We change the provisioning model in a way that all
> mentioned configurations become active exactly with the start level of
> org.apache.felix.configadmin....
Makes sense to me, I can't think of a good reason to activate configs
at specific start levels.
I suppose you just need a component that starts at level 1 and listens
for the ConfigAdmin service availability to implement this.
-Bertrand
Re: Creating a configuration during startup (was Re: [DISCUSS]
Consolidate starter-startup and startupfilter/startupfilter-disabler to use
Apache Felix HC ServiceUnavailableFilter)
Posted by Georg Henzler <gh...@apache.org>.
Hi Robert,
thanks for the reference, SLING-6305 is partly this problem (but not
only as it seems). I fully agree with Felix's comment "I suggest to
attack the problem at the right place" [1] though.
My proposal: We change the provisioning model in a way that all
mentioned configurations become active exactly with the start level of
org.apache.felix.configadmin. As this is the case from second startup on
anyway, I suppose there is a very low risk of regressions (I created [2]
for that.). The same probably has to be changed for the new feature
model (I haven't looked into that yet).
-Georg
[1]
https://lists.apache.org/thread.html/4bc835e3e1d5ffe97fbb7ef7b6a7db02598f313bd2bf708b938b4eef@%3Cdev.sling.apache.org%3E
[2] https://issues.apache.org/jira/browse/SLING-8355
On 2019-04-12 10:49, Robert Munteanu wrote:
> Hi Georg,
>
> On Fri, 2019-04-12 at 00:47 +0200, Georg Henzler wrote:
>> Hi all,
>>
>> I'm trying to add a config to the provisioning model [1] that is
>> active
>> during first startup at startlevel 5. Looking at [2] this does not
>> seem
>> to be possible (or it's not documented). On second startup it's fine
>> since the config is there, but on first startup, the config is only
>> created at startlevel 30 (there is a log for "CM Event Dispatcher"
>> that
>> shows this). Moving the config to boot.txt also does not work. Not
>> sure
>> why the configs are only made active that late on first startup,
>> configadmin would be available from startlevel 1 and from second
>> start
>> on the configs are available early anyway...
>
>
> Maybe related to https://issues.apache.org/jira/browse/SLING-6305 ?
>
> Robert
Re: Creating a configuration during startup (was Re: [DISCUSS]
Consolidate starter-startup and startupfilter/startupfilter-disabler to use
Apache Felix HC ServiceUnavailableFilter)
Posted by Robert Munteanu <ro...@apache.org>.
Hi Georg,
On Fri, 2019-04-12 at 00:47 +0200, Georg Henzler wrote:
> Hi all,
>
> I'm trying to add a config to the provisioning model [1] that is
> active
> during first startup at startlevel 5. Looking at [2] this does not
> seem
> to be possible (or it's not documented). On second startup it's fine
> since the config is there, but on first startup, the config is only
> created at startlevel 30 (there is a log for "CM Event Dispatcher"
> that
> shows this). Moving the config to boot.txt also does not work. Not
> sure
> why the configs are only made active that late on first startup,
> configadmin would be available from startlevel 1 and from second
> start
> on the configs are available early anyway...
Maybe related to https://issues.apache.org/jira/browse/SLING-6305 ?
Robert