felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Quarendon <tom.quaren...@worldprogramming.com>
Subject RE: Config admin: when do the CM_UPDATED, CM_DELETED events actually get called?
Date Mon, 09 Jan 2017 22:02:30 GMT
We started with Amdatu testing, but we've forked off now and use something similar but different.

That method of synchronous config delivery would be hard with DS I think. Maybe doable if
there is an @Modified method, but much harder if not, having to deactivate and reactivate
the component. Not sure you can even do that synchronously. Not sure you can.

I'll investigate the option of waiting for a quiet period in the ServiceEvent stream. Sounds
like a possible route. Downside as you say is that there is then always a pause period before
things progress, but that'll be quicker than repeatedly restarting the CI build until all
the stars align and it goes green, which is what we have to do now...

To be honest this is by far the most frustrating part I find of using OSGi. It seems extremely
hard to make a reliable testing environment.

-----Original Message-----
From: Bram Pouwelse [mailto:bram@pouwelse.com] 
Sent: 09 January 2017 21:20
To: users@felix.apache.org
Subject: Re: Config admin: when do the CM_UPDATED, CM_DELETED events actually get called?

Hi Tom,

Let me start with saying that I'm not sure if the approach works with DS components but we
use Amdatu Testing for our tests, that has an option for synchronous delivery of configurations
[1]. This synchronous delivery mode bypasses ConfigAdmin and applies configuration changes
directly to the ManagedService(Factory).

This has solved a lot of timing issues in tests for us ;)

Another thing you could think about is waiting for the system to settle after a change to
the environment. For example a configuration change will trigger services to become available
or unavailable so it's possible to listen for all ServiceEvents after the configuration change
and continue only if there was no ServiceEvent received in the last <<figure out a good
timeout value>> ms.

The second approach will take a bit longer as the update is still asynchronous and you'll
always have the " timeout period".



On Mon, Jan 9, 2017 at 8:47 PM David Jencks <david.a.jencks@gmail.com>

> Felix DS runs off the configuration events too, so just waiting for 
> the events isn’t going to determine whether you or DS is notified first.
> I’m not sure if you can use serviceRanking to determine which 
> configuration listener gets notified first.  If you can arrange that 
> your listener is called after DS, the configuration event is processed 
> synchronously by DS.
> hope this helps
> david jencks
> > On Jan 9, 2017, at 9:01 AM, Tom Quarendon <
> tom.quarendon@worldprogramming.com> wrote:
> >
> > I'm trying to use the CM_UPDATED and CM_DELETED config admin events 
> > in a
> test harness to ensure that a configuration change has been actioned 
> before the test case gets run, but I'm unclear when exactly these get called.
> >
> > The OSGi specification doesn't seem very enlightening. "An event is
> fired when a call to Configuration.update(Dictionary) successfully 
> changes a configuration".
> > Configuration.update is documented as being actioned asynchronously.
> >
> > For example, I have a component that has a configurationPolicy of
> REQUIRED. In my test harness, in a tear down method (junit @After), I 
> invoke a Configuration.delete method, then wait until the CM_DELETED 
> event is fired.
> > Am I guaranteed that the component has been deactivated by the time 
> > the
> CM_DELETED event gets fired?
> > That's just an example. For UPDATED, if you have a 
> > configurationPolicy
> of REQUIRED, updating the configuration results in a deactivation and 
> reactivation of the component, and consequent deactivation and 
> reactivation of anything that has a required reference to it. Does the 
> CM_UPDATED only occur after all that has happened?
> >
> > Annecdotally I do appear to see components being deactivated before 
> > the
> CM_DELETED event gets called for example. However, what I'm trying to 
> do is solve test case unreliability that we are getting that we 
> believe are caused by background "rewiring" still occurring when the 
> test is then run, I want to be sure.
> >
> > What I'd *really* like is a guaranteed way of saying "come back to 
> > me
> when there's no further wiring to be done, your queue of outstanding 
> configuration changes is empty". Then I know that I can put one of 
> those in my test setup and I know that I've got a stable environment 
> in which to run the test. At the moment, what we appear to see is that 
> there is still reconfiguration going on in the background when tests start.
> >
> > Thanks.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
View raw message