Hi,
Thanks for the update.
I have to admit, that I cannot tell what's going on.
>From the POV of SCR it doesn't matter whether a service used to satisfy
a reference is registered through a regular Bundle Activator or through
SCR -- in fact SCR doesn't even know.
Now, I think I have added fairly extensive logging information in SCR
1.2.0 (or at least I have done in the currently voted on 1.4.0 release
candidate) -- logging mostly done at DEBUG level. This logging should
indicate why SCR is taking down a component (and reactivating it).
Generally a component is reactivated if a statically bound reference has
to be replaced (because the bound reference is unregistered).
Also SCR 1.2.0 reactivates a component if service registration
properties of a bound service are modified through the
ServiceRegistration.setProperties() method. This is a misbehaviour which
has been fixed in 1.4.0.
Regards
Felix
Kris Pruden schrieb:
>
> On Dec 16, 2009, at 12:42 PM, Felix Meschberger wrote:
>
>> Hi,
>>
>> Kris Pruden schrieb:
>>> Hi,
>>>
>>> I'm puzzling through some strange behaviour in my application related to
>>> what appears to be a race and/or some weird interaction between services
>>> registered via SCR and bundles trying to monitor these services via the
>>> ServiceTracker API.
>>>
>>> I don't have any good theories at the moment, so I was hoping if I
>>> described what I'm seeing it might job somebody's memory...
>>>
>>> Here's my situation. I have an application made up of about a
>>> half-dozen or so bundles, most (but not all) of which register their
>>> services using DS/SCR. I'm using pax:exam to run automated functional
>>> tests for this application. Unfortunately, my tests are not reliable -
>>> they fail intermittently. When there's a failure, it's always because
>>> of an NPE on one of the SCR-injected @Reference attributes of a
>>> service/component. It's hard to tell for sure, but what looks like is
>>> happening is this:
>>> 1. The SCR starts and registers a component/service
>>> 2. The functional test, which was waiting for that service to become
>>> available, gets a reference to the service
>>> 3. The SCR stops the service, then immediately starts and registers a
>>> new instance of the service
>>>
>>> Unfortunately, at this point the test bundle now has a reference to the
>>> "stopped" instance of the service, which has had all of its @Reference
>>> fields set to null (hence the NPE).
>>>
>>> What I can't figure out is why this is happening.
>>>
>>> Anyone have any suggestions about where I should look next, or any known
>>> SCR gotchas that I might be running into?
>>
>> Well, from far outside, it must be said, that a service may come and go
>> at any time for any reason...
>>
>> Now, this doesn't help you, of course. But without a more in-depth look
>> into the situation I cannot tell much, other than: It should work
>> actually.
>>
>> Let me quickly recapitulate:
>>
>> Your component under test is a SCR component which also is registered as
>> a service: Is this a delayed service component or a service factory
>> component ?
>
> It's not a factory, and it is configured to start immediately. These
> are the annotations on the service in question:
>
> @Component(immediate=true)
> @Service
>
>> SCR stops and immediately restarts the service: Are you updating
>> configuration admin configuration supplied to the component during the
>> test ?
>
> Not as far as I know. I should point out that I'm not 100% sure that my
> claim of the start/stop/start behaviour is in fact true. I see evidence
> that this happens - I've seen log output from the SCR announcing the
> activation of a component, then another message indicating that it's
> deactivated, then another one saying it's activated again. I've
> instrumented the activate/deactivate methods on the service
> implementation and confirmed that this is in fact happening, and that
> the second activation is a new instance of the service class. However,
> even in cases where I don't see this happening, I still am seeing the
> NPE from time to time (more on this).
>
>> You talk about a @Reference annotation: Does this mean the SCR component
>> under test has a reference to another service ? Is this reference
>> mandatory or optional ? Is it static or dynamic ? Is there a change in
>> the referenced service during the test ?
>
> Yes, so to be a bit more concrete I have the service my functional test
> is exercising, call it ServiceA. This service is annotated as above and
> contains a dependency on a second service, ServiceB. The class
> definition looks something like this:
>
> @Component(immediate=true)
> @Service
> public class ServiceAImpl implements ServiceA {
> @Reference
> ServiceB serviceB;
>
> ...
> }
>
> ServiceB is similarly defined, and (maybe this is relevant) has its own
> dependencies on other services, also injected via the @Reference
> annotation as above, but at least one of these is not itself managed via
> SCR (that is, it's a regular old service registered via a bundle
> activator). Further (again, not sure if it's relevant), this non-DS
> service is actually provided via a ServiceFactory...
>
>> Last but not least: What DS implementation are you using ? Or: what
>> version of Felix SCR are you using ?
>
> We're using Felix SCR 1.2.0.
>
> One other data point: I'm pretty sure the issue is at least somewhat
> timing related. The reason is that I have tried the build on two
> separate computers, one a (relatively) slow laptop (a macbook pro), the
> other a quite powerful workstation (quad-core, 8GB RAM, running linux).
> The tests reliably *pass* on the slow laptop, but fairly reliably
> *fails* on the fast machine. My theory is that the fast machine is
> winning the race against SCR in this start/stop/start loop (and
> therefore losing) while the slow machine is losing that race...
>
> I'm still running experiments; I'll update with any new data I find that
> I think might be helpful. I realize issues like this are hard enough to
> figure out when you're watching them happen, so I don't really expect
> you to know what's going on here (although if you do that would be
> awesome). Mostly I'm just wondering if this setup is tickling a known
> timing issue or something along those lines...
>
> Thanks again,
>
> Kris
>
>> Regards
>> Felix
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
