You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by David Jencks <da...@yahoo.com> on 2013/02/23 23:42:00 UTC
Race condition in DS configuring new components
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 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….
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.
Thoughts? Any other ideas?
many thanks
david jencks
Re: Race condition in DS configuring new components
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 25.02.2013 um 05:42 schrieb David Jencks:
> I attached a patch to 3915 with an implementation that should use the R5 changeCount if available, and does something like the last commit if not. I haven't found a R5 compendium in maven yet, so I'm using reflection. Hoping to update soon. WDYT?
The enterprise JAR is available at version 5.0.0 from Maven and provides the updated Configuration Admin 1.5 API.
Just make sure to not require Configuration Admin 1.5 for deployment of SCR: It should gracefully fall back to duplicate configuration delivery if cm<1.5 and Configuration.getChangeCount() is not available.
>
> The MS/MSF approach won't work in general in R5 because of targetPids. I'm going to look at implementing support for these and the location changed event.
Great, that is a big missing thing (and issues exist for these, IIRC). Thanks alot.
Regards
Felix
>
> thanks
> david jencks
>
> On Feb 24, 2013, at 11:00 AM, David Jencks <da...@yahoo.com> wrote:
>
>> 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 <fm...@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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
--
Felix Meschberger | Principal Scientist | Adobe
Re: Race condition in DS configuring new components
Posted by David Jencks <da...@yahoo.com>.
I attached a patch to 3915 with an implementation that should use the R5 changeCount if available, and does something like the last commit if not. I haven't found a R5 compendium in maven yet, so I'm using reflection. Hoping to update soon. WDYT?
The MS/MSF approach won't work in general in R5 because of targetPids. I'm going to look at implementing support for these and the location changed event.
thanks
david jencks
On Feb 24, 2013, at 11:00 AM, David Jencks <da...@yahoo.com> wrote:
> 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 <fm...@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
>>
>>
>>
>>
>>
>>
>>
>
Re: Race condition in DS configuring new components
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 24.02.2013 um 20:00 schrieb David Jencks:
> 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.
MS won't work with multiple PIDs (yes I have thought of that, too) because the PID is not available if (a) there is no configuration for a specific PID on first registration and (b) if a configuration is deleted (i.e. you don't know which configuration was removed !).
> (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.
I am not sure about the requirement to deliver on a single thread: I just remember that the MS/MSF have to be updated on a thread different to the thread doing the call to Configuration.update(Dictionary).
Regards
Felix
>
> many thanks!
> david jencks
>
> On Feb 24, 2013, at 5:37 AM, Felix Meschberger <fm...@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
>>
>>
>>
>>
>>
>>
>>
>
--
Felix Meschberger | Principal Scientist | Adobe
Re: Race condition in DS configuring new components
Posted by David Jencks <da...@yahoo.com>.
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 <fm...@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
>
>
>
>
>
>
>
Re: Race condition in DS configuring new components
Posted by Felix Meschberger <fm...@adobe.com>.
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