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 <[email protected]> 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
