felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jens Offenbach" <wolle5...@gmx.de>
Subject Aw: Re: SCR: Sometimes component gets instantiated twice
Date Thu, 10 Mar 2016 11:18:51 GMT
I have built SCR from the felix repository and made some test runs: It seems that your fix
is working properly, the issue has disappeared :-) but I cannot say it with certainty. Race
conditions are so difficult to observe and especially to fix in complex scenarios.

I will do some more test runs and next days. I am looking forward to SCR 2.0.3

Thank you very much for your help.

Regards,
Jens

Gesendet: Mittwoch, 09. März 2016 um 17:29 Uhr
Von: "David Jencks" <david_jencks@yahoo.com.INVALID>
An: users@felix.apache.org
Betreff: Re: SCR: Sometimes component gets instantiated twice
Can you check if this still happens with trunk? I recently fixed https://issues.apache.org/jira/browse/FELIX-5194
<https://issues.apache.org/jira/browse/FELIX-5194[https://issues.apache.org/jira/browse/FELIX-5194]>
which is a race condition on component startup between querying config admin and getting the
initial configuration event.

david jencks

> On Mar 9, 2016, at 6:08 AM, Jens Offenbach <wolle5050@gmx.de> wrote:
>
> It has something to do with the TargetedPID. The modified or deactivate method gets called
when oldTargetedPID is null. Why is it sometimes null? Is it possible that the component got
instantiated and configured, but has a TargetedPID of null?
>
> ConfigurationSupport.java (Line 338):
> TargetedPID oldTargetedPID = componentHolder.getConfigurationTargetedPID(pid, factoryPid);
> if ( targetedPid.equals(oldTargetedPID))
> ...
> }
>
>
> Gesendet: Mittwoch, 09. März 2016 um 14:44 Uhr
> Von: "Carsten Ziegeler" <cziegeler@apache.org>
> An: users@felix.apache.org
> Betreff: Re: SCR: Sometimes component gets instantiated twice
> Jens Offenbach wrote
>> Now, I am confused... But I am using 'configuration-policy="require"'. This should
force SCR to activate my component only when there is a valid configuration.
>>
>
> Your configuration is changed, config admin fires a configuration
> changed event, which in turn reactivates your component. It might be the
> same configuration, but as someone updated the config, config admin
> needs to send out the event.
>
> If you don't implement modified, your component is deactivated and then
> activated. Otherwise modified is called.
>
> As you have require as the configuration policy, the only way to avoid
> this is to make sure that the configuration is not updated in config admin.
>
> So this is not an SCR problem, everything behaves as expected. It looks
> rather like a provisioning problem to me.
>
> In general, OSGi is dynamic, so your component should behave properly
> and expect this "restarting" through a configuration change.
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message