You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by James Carman <ja...@carmanconsulting.com> on 2016/08/02 19:53:51 UTC

[DISCUSSS] Duplicate persistent-id usage can cause bundle restart loop...

When two different bundles use the same configuration pid, you can get into
a very weird restart loop (at least with blueprint).  It violates the
specification for two bundles to try to use the same configuration.
Shouldn't we just fail to start the second bundle if the pid is already
"claimed"?

James

Re: [DISCUSSS] Duplicate persistent-id usage can cause bundle restart loop...

Posted by James Carman <ja...@carmanconsulting.com>.
This appears to just be a Blueprint thing.  I tried replicating the looping
issue with simple ManagedServices and that worked just fine.  I got an
ERROR log:

07:19:21,467 | ERROR | CM Configuration Updater (Update:
pid=com.carmanconsulting.karaf.whiteboard) | ?
      ? | 6 - org.apache.felix.configadmin - 1.8.4 |  | Cannot use
configuration com.carmanconsulting.karaf.whiteboard for
[org.osgi.service.cm.ManagedService, id=1013,
bundle=289/mvn:com.carmanconsulting.karaf/karaf-whiteboard-bundle2/1.0.0-SNAPSHOT]:
No visibility to configuration bound to
mvn:com.carmanconsulting.karaf/karaf-whiteboard-bundle1/1.0.0-SNAPSHOT

However, when you use blueprint and the "property-placeholder" (with
update-strategy="reload"), it's a whole different story.  I have checked in
a small project (with a couple other modules in it) that exhibits the issue:

https://github.com/jwcarman/karaf-whiteboard

The README shows how to install it.  Now, keep in mind that this behavior
isn't consistent.  But, try it a few times and you will see the looping it
does in the logs.

On Wed, Aug 3, 2016 at 6:48 AM James Carman <ja...@carmanconsulting.com>
wrote:

> Right, what I'm saying is that Karaf doesn't behave very nicely when two
> ManagedService's try to use the same service.pid. I want it to barf on the
> second one and not go into its crazy loop that it does.
>
> On Wed, Aug 3, 2016 at 12:53 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
>> Hi James,
>>
>> you are right only for the ManagedService. If several bundles directly
>> read the configuration with ConfigAdmin (using directly the service),
>> than there is no problem.
>>
>> The problem occurs only when you have several ManagedService on the same
>> config (called when the configuration change especially).
>>
>> Regards
>> JB
>>
>> On 08/02/2016 09:53 PM, James Carman wrote:
>> > When two different bundles use the same configuration pid, you can get
>> into
>> > a very weird restart loop (at least with blueprint).  It violates the
>> > specification for two bundles to try to use the same configuration.
>> > Shouldn't we just fail to start the second bundle if the pid is already
>> > "claimed"?
>> >
>> > James
>> >
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>

Re: [DISCUSSS] Duplicate persistent-id usage can cause bundle restart loop...

Posted by James Carman <ja...@carmanconsulting.com>.
Agreed.  Karaf just seems to be suffering from the bug, though.  We should
work with the Aries team to resolve the issue.  Karaf goes into a crazy
looping state (which eventually seems to settle down), so I would think
we'd want to get it fixed.

On Wed, Aug 3, 2016 at 8:02 AM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:

> IMHO, it's not a Karaf issue but more a blueprint-cm issue.
>
> Regards
> JB
>
> On 08/03/2016 12:48 PM, James Carman wrote:
> > Right, what I'm saying is that Karaf doesn't behave very nicely when two
> > ManagedService's try to use the same service.pid. I want it to barf on
> the
> > second one and not go into its crazy loop that it does.
> >
> > On Wed, Aug 3, 2016 at 12:53 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> > wrote:
> >
> >> Hi James,
> >>
> >> you are right only for the ManagedService. If several bundles directly
> >> read the configuration with ConfigAdmin (using directly the service),
> >> than there is no problem.
> >>
> >> The problem occurs only when you have several ManagedService on the same
> >> config (called when the configuration change especially).
> >>
> >> Regards
> >> JB
> >>
> >> On 08/02/2016 09:53 PM, James Carman wrote:
> >>> When two different bundles use the same configuration pid, you can get
> >> into
> >>> a very weird restart loop (at least with blueprint).  It violates the
> >>> specification for two bundles to try to use the same configuration.
> >>> Shouldn't we just fail to start the second bundle if the pid is already
> >>> "claimed"?
> >>>
> >>> James
> >>>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: [DISCUSSS] Duplicate persistent-id usage can cause bundle restart loop...

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
IMHO, it's not a Karaf issue but more a blueprint-cm issue.

Regards
JB

On 08/03/2016 12:48 PM, James Carman wrote:
> Right, what I'm saying is that Karaf doesn't behave very nicely when two
> ManagedService's try to use the same service.pid. I want it to barf on the
> second one and not go into its crazy loop that it does.
>
> On Wed, Aug 3, 2016 at 12:53 AM Jean-Baptiste Onofr� <jb...@nanthrax.net>
> wrote:
>
>> Hi James,
>>
>> you are right only for the ManagedService. If several bundles directly
>> read the configuration with ConfigAdmin (using directly the service),
>> than there is no problem.
>>
>> The problem occurs only when you have several ManagedService on the same
>> config (called when the configuration change especially).
>>
>> Regards
>> JB
>>
>> On 08/02/2016 09:53 PM, James Carman wrote:
>>> When two different bundles use the same configuration pid, you can get
>> into
>>> a very weird restart loop (at least with blueprint).  It violates the
>>> specification for two bundles to try to use the same configuration.
>>> Shouldn't we just fail to start the second bundle if the pid is already
>>> "claimed"?
>>>
>>> James
>>>
>>
>> --
>> Jean-Baptiste Onofr�
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>

-- 
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [DISCUSSS] Duplicate persistent-id usage can cause bundle restart loop...

Posted by James Carman <ja...@carmanconsulting.com>.
Right, what I'm saying is that Karaf doesn't behave very nicely when two
ManagedService's try to use the same service.pid. I want it to barf on the
second one and not go into its crazy loop that it does.

On Wed, Aug 3, 2016 at 12:53 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:

> Hi James,
>
> you are right only for the ManagedService. If several bundles directly
> read the configuration with ConfigAdmin (using directly the service),
> than there is no problem.
>
> The problem occurs only when you have several ManagedService on the same
> config (called when the configuration change especially).
>
> Regards
> JB
>
> On 08/02/2016 09:53 PM, James Carman wrote:
> > When two different bundles use the same configuration pid, you can get
> into
> > a very weird restart loop (at least with blueprint).  It violates the
> > specification for two bundles to try to use the same configuration.
> > Shouldn't we just fail to start the second bundle if the pid is already
> > "claimed"?
> >
> > James
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: [DISCUSSS] Duplicate persistent-id usage can cause bundle restart loop...

Posted by David Jencks <da...@yahoo.com.INVALID>.
That doesn’t seem entirely accurate to me.

If the bundle location on the config is set to a multi-location any bundle with appropriate permissions (i.e. all if you aren’t enforcing permissions) will have visibility into the configuration.
If the bundle location is set but not to a multi-location then:
- only ManagedService/ManagedServiceFactory instances in that bundle will be notified
- DS and any other well-behaved extender will only use that configuration for components in that bundle
- both getConfiguration methods and the listConfiguration method will return the configuration unmodified (permissions allowing)

If the bundle location is null then:
- the first ManagedService/ManagedServiceFactory to get notified will “claim” the configuration as CA will set the bundleLocation to that of the containing bundle
- code using listConfiguration or getConfiguration(pid, null) won’t “claim” the configuration
- code using getConfiguration(pid) or getConfiguration(pid, location) will set the bundleLocation, “claiming” it
- extenders such as blueprint or DS should either be implemented using ManagedService/ManagedServiceFactory or not claim the configuration.  There’s no safe way to identify and claim a configuration outside of the config admin implementation itself.  Felix DS never modifies the bundle location.  I’d expect Aries blueprint to have the same situation but haven’t looked.

For maximum flexibility I’d think that karaf should provide a way to specify the bundle location for a configuration, basically so you can set it to “?”.

Hope this isn’t too long-winded.

thanks
david jencks

> On Aug 2, 2016, at 9:52 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> 
> Hi James,
> 
> you are right only for the ManagedService. If several bundles directly read the configuration with ConfigAdmin (using directly the service), than there is no problem.
> 
> The problem occurs only when you have several ManagedService on the same config (called when the configuration change especially).
> 
> Regards
> JB
> 
> On 08/02/2016 09:53 PM, James Carman wrote:
>> When two different bundles use the same configuration pid, you can get into
>> a very weird restart loop (at least with blueprint).  It violates the
>> specification for two bundles to try to use the same configuration.
>> Shouldn't we just fail to start the second bundle if the pid is already
>> "claimed"?
>> 
>> James
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com


Re: [DISCUSSS] Duplicate persistent-id usage can cause bundle restart loop...

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi James,

you are right only for the ManagedService. If several bundles directly 
read the configuration with ConfigAdmin (using directly the service), 
than there is no problem.

The problem occurs only when you have several ManagedService on the same 
config (called when the configuration change especially).

Regards
JB

On 08/02/2016 09:53 PM, James Carman wrote:
> When two different bundles use the same configuration pid, you can get into
> a very weird restart loop (at least with blueprint).  It violates the
> specification for two bundles to try to use the same configuration.
> Shouldn't we just fail to start the second bundle if the pid is already
> "claimed"?
>
> James
>

-- 
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com