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]
