You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Paul Stanley <pj...@live.co.uk> on 2021/05/05 15:07:11 UTC

Non-Deterministic startup order

Hi.

When building and running karaf the boot order for the initial set of startup bundles is being randomised, within their start levels.  As result we are seeing non-deterministic behaviour between development and release builds of custom karaf platforms.

Please can you change the karaf.features.core and the karaf.profile.core to use LinkedHashMaps and Sets, to preserve the order of bundles as discovered in the feature.xml files.

Thanks
Paul


Re: Non-Deterministic startup order

Posted by Paul Stanley <pj...@live.co.uk>.
Hi Romain,
I've been using 4.3.0.  I'll give 4.3.2 a go when I get a chance.
Cheers
Paul

________________________________
From: Romain Manni-Bucau <rm...@gmail.com>
Sent: 05 May 2021 16:10
To: dev <de...@karaf.apache.org>
Subject: Re: Non-Deterministic startup order

Hi Paul,

Did you use the last 4.3 release? Startup bundles shouldn't be randomized
anymore. For features it is a bit more complicated since it is a tree so
guess order can't really be assumed without side effects (whereas it can
for a flat list of bundles).

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 5 mai 2021 à 17:07, Paul Stanley <pj...@live.co.uk> a écrit :

> Hi.
>
> When building and running karaf the boot order for the initial set of
> startup bundles is being randomised, within their start levels.  As result
> we are seeing non-deterministic behaviour between development and release
> builds of custom karaf platforms.
>
> Please can you change the karaf.features.core and the karaf.profile.core
> to use LinkedHashMaps and Sets, to preserve the order of bundles as
> discovered in the feature.xml files.
>
> Thanks
> Paul
>
>

Re: Non-Deterministic startup order

Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi Paul,

You are mixing two things: the generation of the startup.properties at build time, and the actual order at runtime.

My point was about the start level at runtime, not build/startup.properties generation.

We use start-level in Karaf to define the order, and it’s cleanly sorted. What we do is to pass the start level in the features definition:

https://github.com/apache/karaf/blob/main/assemblies/features/framework/src/main/feature/feature.xml <https://github.com/apache/karaf/blob/main/assemblies/features/framework/src/main/feature/feature.xml>

Then, we define the feature as startupFeature and the startup.properties is generated using the start-level defined in the feature definition.

Do you use the same approach or directly startupBundles ?

Regards
JB

> Le 11 mai 2021 à 16:38, Paul Stanley <pj...@live.co.uk> a écrit :
> 
> Hello.
> 
> I have tested the proposed 4.3.2 release and the startup.properties file is still being generated in a non- deterministic order.  They are grouped in their start level, but within that they are listed in a random order.
> 
> The issue we have been seeing relates to the jetty distribution which listed in the startup.properties file as part of our custom installation, given the unpredictable order has led to the web server restarting a number of times during the boot cycle, this in turn can prevent karaf from starting.
> 
> It appears that the problem is in the builder class in the profile project.  This does attempt to sort the bundles, but the startupEffective.getBundles() list is empty and as such the sort operation has no effect.  Would it be possible to updated the resolve() method and the MapUtils class to use LinkedHashMaps when using the Collectors.toMap() stream operations.
> 
> Thanks
> Paul
> 
> ________________________________
> From: Romain Manni-Bucau <rm...@gmail.com>
> Sent: 05 May 2021 16:10
> To: dev <de...@karaf.apache.org>
> Subject: Re: Non-Deterministic startup order
> 
> Hi Paul,
> 
> Did you use the last 4.3 release? Startup bundles shouldn't be randomized
> anymore. For features it is a bit more complicated since it is a tree so
> guess order can't really be assumed without side effects (whereas it can
> for a flat list of bundles).
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> 
> Le mer. 5 mai 2021 à 17:07, Paul Stanley <pj...@live.co.uk> a écrit :
> 
>> Hi.
>> 
>> When building and running karaf the boot order for the initial set of
>> startup bundles is being randomised, within their start levels.  As result
>> we are seeing non-deterministic behaviour between development and release
>> builds of custom karaf platforms.
>> 
>> Please can you change the karaf.features.core and the karaf.profile.core
>> to use LinkedHashMaps and Sets, to preserve the order of bundles as
>> discovered in the feature.xml files.
>> 
>> Thanks
>> Paul
>> 
>> 


Re: Non-Deterministic startup order

Posted by Paul Stanley <pj...@live.co.uk>.
Hello.

I have tested the proposed 4.3.2 release and the startup.properties file is still being generated in a non- deterministic order.  They are grouped in their start level, but within that they are listed in a random order.

The issue we have been seeing relates to the jetty distribution which listed in the startup.properties file as part of our custom installation, given the unpredictable order has led to the web server restarting a number of times during the boot cycle, this in turn can prevent karaf from starting.

It appears that the problem is in the builder class in the profile project.  This does attempt to sort the bundles, but the startupEffective.getBundles() list is empty and as such the sort operation has no effect.  Would it be possible to updated the resolve() method and the MapUtils class to use LinkedHashMaps when using the Collectors.toMap() stream operations.

Thanks
Paul

________________________________
From: Romain Manni-Bucau <rm...@gmail.com>
Sent: 05 May 2021 16:10
To: dev <de...@karaf.apache.org>
Subject: Re: Non-Deterministic startup order

Hi Paul,

Did you use the last 4.3 release? Startup bundles shouldn't be randomized
anymore. For features it is a bit more complicated since it is a tree so
guess order can't really be assumed without side effects (whereas it can
for a flat list of bundles).

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 5 mai 2021 à 17:07, Paul Stanley <pj...@live.co.uk> a écrit :

> Hi.
>
> When building and running karaf the boot order for the initial set of
> startup bundles is being randomised, within their start levels.  As result
> we are seeing non-deterministic behaviour between development and release
> builds of custom karaf platforms.
>
> Please can you change the karaf.features.core and the karaf.profile.core
> to use LinkedHashMaps and Sets, to preserve the order of bundles as
> discovered in the feature.xml files.
>
> Thanks
> Paul
>
>

Re: Non-Deterministic startup order

Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Paul,

Did you use the last 4.3 release? Startup bundles shouldn't be randomized
anymore. For features it is a bit more complicated since it is a tree so
guess order can't really be assumed without side effects (whereas it can
for a flat list of bundles).

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 5 mai 2021 à 17:07, Paul Stanley <pj...@live.co.uk> a écrit :

> Hi.
>
> When building and running karaf the boot order for the initial set of
> startup bundles is being randomised, within their start levels.  As result
> we are seeing non-deterministic behaviour between development and release
> builds of custom karaf platforms.
>
> Please can you change the karaf.features.core and the karaf.profile.core
> to use LinkedHashMaps and Sets, to preserve the order of bundles as
> discovered in the feature.xml files.
>
> Thanks
> Paul
>
>

Re: Non-Deterministic startup order

Posted by Steinar Bang <sb...@dod.no>.
>>>>> Jean-Baptiste Onofre <jb...@nanthrax.net>:

> And just to let you know that I created https://issues.apache.org/jira/browse/KARAF-7130 <https://issues.apache.org/jira/browse/KARAF-7130> to be able to have a pluggable startup order strategy (for instance based on symbolic name).

A "thumbs-up" on that Jira! :-)


Re: Non-Deterministic startup order

Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi Paul,

It should be deterministic since Karaf 4.3.1.

And just to let you know that I created https://issues.apache.org/jira/browse/KARAF-7130 <https://issues.apache.org/jira/browse/KARAF-7130> to be able to have a pluggable startup order strategy (for instance based on symbolic name).

Regards
JB

> Le 5 mai 2021 à 17:07, Paul Stanley <pj...@live.co.uk> a écrit :
> 
> Hi.
> 
> When building and running karaf the boot order for the initial set of startup bundles is being randomised, within their start levels.  As result we are seeing non-deterministic behaviour between development and release builds of custom karaf platforms.
> 
> Please can you change the karaf.features.core and the karaf.profile.core to use LinkedHashMaps and Sets, to preserve the order of bundles as discovered in the feature.xml files.
> 
> Thanks
> Paul
>