Auto installed bundle fragment inconsistently RESOLVED or INSTALLED on startup

[Andreas Egloff <an...@forgerock.com>]

We have one bundle fragment that does not consistently go to RESOLVED state
after a re-start, but occasionally stays INSTALLED without a visible
failure. We have not observed issues with other fragments we use.

The bundle fragment is installed via config.properties, although the same
seemingly random behavior was observed when placing the fragment alongside
the host bundle in the auto start dir.
felix.auto.install.1

The bundle it attaches to is a bundle in the auto start directory (start
level 10).

The fragment imports one additional package (auto started bundle with start
level 1); the intent being to attach this to the host.

It seems to be reproducible more so on some platforms/environments than
others. Typically the first start is successful; with subsequent restarts
randomly working or not.

Enabling org.osgi.framework.storage.clean=onFirstInit seems to resolve or
improve the situation, but in case this is a timing/ordering issue it is
possible that this is not fully resolving the cause. It also seems more
reproducible on some platforms/environments than others.

Would you have recommendations on obtaining further data/output as to why
the fragment does not consistently go to RESOLVED?

Thanks
Andi

Re: Auto installed bundle fragment inconsistently RESOLVED or INSTALLED on startup

[Andreas Egloff <an...@forgerock.com>]

Thanks Richard, so far I have not noticed anything useful. I'll see what I
can extract.
Andi

On Wed, Oct 19, 2011 at 11:41 AM, Richard S. Hall <he...@ungoverned.org>wrote:

> Perhaps you could set felix.log.level to 4 in conf/config.properties to see
> if you get any additional information. If not, perhaps you could zip
> something up and send it to me privately to see if I could recreate it?
>
> -> richard
>
>
> On 10/19/11 12:26 , Andreas Egloff wrote:
>
>> We have one bundle fragment that does not consistently go to RESOLVED
>> state
>> after a re-start, but occasionally stays INSTALLED without a visible
>> failure. We have not observed issues with other fragments we use.
>>
>> The bundle fragment is installed via config.properties, although the same
>> seemingly random behavior was observed when placing the fragment alongside
>> the host bundle in the auto start dir.
>> felix.auto.install.1
>>
>> The bundle it attaches to is a bundle in the auto start directory (start
>> level 10).
>>
>> The fragment imports one additional package (auto started bundle with
>> start
>> level 1); the intent being to attach this to the host.
>>
>> It seems to be reproducible more so on some platforms/environments than
>> others. Typically the first start is successful; with subsequent restarts
>> randomly working or not.
>>
>> Enabling org.osgi.framework.storage.**clean=onFirstInit seems to resolve
>> or
>> improve the situation, but in case this is a timing/ordering issue it is
>> possible that this is not fully resolving the cause. It also seems more
>> reproducible on some platforms/environments than others.
>>
>> Would you have recommendations on obtaining further data/output as to why
>> the fragment does not consistently go to RESOLVED?
>>
>> Thanks
>> Andi
>>
>>

Re: Auto installed bundle fragment inconsistently RESOLVED or INSTALLED on startup

["Richard S. Hall" <he...@ungoverned.org>]

Perhaps you could set felix.log.level to 4 in conf/config.properties to 
see if you get any additional information. If not, perhaps you could zip 
something up and send it to me privately to see if I could recreate it?

-> richard

On 10/19/11 12:26 , Andreas Egloff wrote:
> We have one bundle fragment that does not consistently go to RESOLVED state
> after a re-start, but occasionally stays INSTALLED without a visible
> failure. We have not observed issues with other fragments we use.
>
> The bundle fragment is installed via config.properties, although the same
> seemingly random behavior was observed when placing the fragment alongside
> the host bundle in the auto start dir.
> felix.auto.install.1
>
> The bundle it attaches to is a bundle in the auto start directory (start
> level 10).
>
> The fragment imports one additional package (auto started bundle with start
> level 1); the intent being to attach this to the host.
>
> It seems to be reproducible more so on some platforms/environments than
> others. Typically the first start is successful; with subsequent restarts
> randomly working or not.
>
> Enabling org.osgi.framework.storage.clean=onFirstInit seems to resolve or
> improve the situation, but in case this is a timing/ordering issue it is
> possible that this is not fully resolving the cause. It also seems more
> reproducible on some platforms/environments than others.
>
> Would you have recommendations on obtaining further data/output as to why
> the fragment does not consistently go to RESOLVED?
>
> Thanks
> Andi
>