Debugging applications - OSGi in Action - page 288

concentrate your search on those three bundles. This is another benefit of modular-
ity: by enforcing module boundaries and interacting indirectly via the service registry,
you reduce the contact points between modules. You no longer have to read through
or instrument the entire code base for potential references, because different con-
cerns are kept separate from one another. But regardless of how much code you have
to look through, you can use a couple of techniques to narrow the search, ranging
from high-level queries to low-level monitoring.

QUERYING THE FRAMEWORK
You can per form high-level monitoring by using facilities built into the OSG i frame-
work to track service use. The Bundle API has a method called getServicesInUse() to
tell you which services the OSG i framework believes a given bundle is actively using at
any given time. Remember from chapter 4 that this is done by tracking calls to
getService() and ungetService() . Unfortunately, many developers and even some
service-based frameworks don't call ungetService() when they're done with a service,
which can lead you to think there is a leak where there isn't one. This approach
also doesn't detect when a direct reference to the service escapes from the bundle
into some long-lived field. You can also use the getUsingBundles() method from the
ServiceReference API to perform a reverse check and find out which bundles are
using a given service, but this too doesn't account for incorrectly cached instances.

MONITORING WITH JVMTI
Low-level monitoring is possible using the JVM Tools Interface ( JVMTI , http://
java.sun.com/javase/6/docs/platform/jvmti/jvmti.html ) . JVMTI is a native API that
provides several ways to interrogate, intercept, and introspect aspects of the JVM such
as the Java heap, locks, and threads. There are open source agents that can analyze
the heap to find leak candidates. It should be possible to take these generic agents
and develop them further to add knowledge about OSG i resources, so they can watch
for references to OSG i service instances on the Java heap and determine which bundle
is responsible for holding on to them. A recent example of this is the OSG i inspector
agent ( http://wiki.github.com/mirkojahn/ OSG i-Inspector/ ) .
Just as you saw when debugging, it's one thing to find out why something is hap-
pening; being able to do something about it (and, in this case, protect against it) is
even more important.

8.4.2 Protecting against dangling services

The simplest way to protect against dangling services is to let a component framework
such as Declarative Services manage services for you. Component frameworks are dis-
cussed in detail in chapters 11 and 12; for now, you can think of them as watchful par-
ents that protect their children from the harsh realities of the world. But even
component frameworks may not be able to help against rogue clients that stubbornly
refuse to relinquish references to your service. You somehow need to give these bun-
dles a reference that you can clear yourself, without requiring their cooperation.