You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Tom Quarendon <to...@worldprogramming.com> on 2017/01/09 17:01:22 UTC
Config admin: when do the CM_UPDATED, CM_DELETED events actually get
called?
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.
RE: Config admin: when do the CM_UPDATED, CM_DELETED events actually
get called?
Posted by Tom Quarendon <to...@worldprogramming.com>.
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".
Regards,
Bram
1:
https://bitbucket.org/amdatu/amdatu-testing/src/bd5d65ffd556dfa2b7cd933c22ba36c87a5e9326/org.amdatu.testing.configurator/src/org/amdatu/testing/configurator/ServiceConfigurator.java?at=master&fileviewer=file-view-default#ServiceConfigurator.java-71
On Mon, Jan 9, 2017 at 8:47 PM David Jencks <da...@gmail.com>
wrote:
> 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
>
>
Re: Config admin: when do the CM_UPDATED, CM_DELETED events actually
get called?
Posted by Bram Pouwelse <br...@pouwelse.com>.
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".
Regards,
Bram
1:
https://bitbucket.org/amdatu/amdatu-testing/src/bd5d65ffd556dfa2b7cd933c22ba36c87a5e9326/org.amdatu.testing.configurator/src/org/amdatu/testing/configurator/ServiceConfigurator.java?at=master&fileviewer=file-view-default#ServiceConfigurator.java-71
On Mon, Jan 9, 2017 at 8:47 PM David Jencks <da...@gmail.com>
wrote:
> 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
>
>
RE: Config admin: when do the CM_UPDATED, CM_DELETED events actually
get called?
Posted by Tom Quarendon <to...@worldprogramming.com>.
> I’m not sure if my suggestion would continue to work i R7 due to coordination support.
Sorry, expand please?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Config admin: when do the CM_UPDATED, CM_DELETED events actually
get called?
Posted by David Jencks <da...@gmail.com>.
I’m not sure if my suggestion would continue to work i R7 due to coordination support.
david jencks
> On Jan 9, 2017, at 11:46 AM, David Jencks <da...@gmail.com> wrote:
>
> 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 <to...@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
Re: Config admin: when do the CM_UPDATED, CM_DELETED events actually
get called?
Posted by David Jencks <da...@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 <to...@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