felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Race condition in DS configuring new components
Date Sun, 24 Feb 2013 19:00:10 GMT
Hi Felix,

(1) I'll think about whether there's a way to use the revision counter only if present.  Unless
I hear of a good reason otherwise I think leaving things as they are is probably a good idea.

(2) My idea about the MS/ MSF (after some more thinking) would be to
(a) register just one MS and one MSF and keep changing the pids in the ServiceRegistration
to reflect the currently enabled components.  ConfigAdmin should be able to use this to track
what it should do.
(b) Do an initial query and use a configuration listener to keep track of the pids and factorypids
CA knows about to decide whether a configuration PID is singleton or factory.

Since CA has to deliver configuration events on a single thread (per component) in order,
and internally it can do appropriate locking, I think that in fact using MS/MSF would result
in correct behavior, with no duplicates between initial configuration and any "later" events.
 But this solution is definitely more complicated.

many thanks!
david jencks

On Feb 24, 2013, at 5:37 AM, Felix Meschberger <fmeschbe@adobe.com> wrote:

> Hi David,
> 
> Am 23.02.2013 um 23:42 schrieb David Jencks:
> 
>> There's a race condition in DS between registering a new component holder for existing
configuration and processing configuration events.  Before FELIX-3912 it was possible to completely
miss a configuration for a new component holder if the configuration arrived between the query
for existing configurations and the registration of the holder for configuration updates.
 I switched the order, and now there's a chance a configuration update will be applied twice.
(even after my second commit on this)
>> 
>> Is this a problem?
> 
> I think not. It is probably better to have a chance of double configuration than to have
a risk of missing configuration.
> 
> The latest Config Admin spec introduces a revision counter to the Configuration object.
DS could check that -- but this would require the latest Config Admin spec. Not sure, whether
this would be worth it.
> 
>> 
>> I think a solution would be to register a ManagedService or ManagedServiceFactory
for each component holder, since then the initial configuration and all updates would occur
on the same thread.  This seems like a lot of services….  
> 
> Yes, and it does not help. (a) MS and MSF are also called asynchronously and (b) to support
both factory and singleton configurations (whatever is present) both MS and MSF would be required.
Even more services.
> 
>> 
>> I haven't thought much but I think to distinguish between MS and MSF we need to query
the initial set and look for events to determine whether there's a factoryPID or just PID
and use that to decide.
> 
> If there is no initial configuration you don't have anything to decide on ...
> 
>> 
>> Thoughts? Any other ideas?
> 
> I think it suffices it to register before checking and risk "double" configuration in
edge cases.
> 
> Regards
> Felix
> 
> 
>> 
>> many thanks
>> david jencks
>> 
> 
> 
> --
> Felix Meschberger | Principal Scientist | Adobe
> 
> 
> 
> 
> 
> 
> 


Mime
View raw message