A Practical Approach for Finding Stale References in a Dynamic Service Platform

Abstract

Abstract. The OSGi™ Service Platform is becoming the de facto standard for modularized Java applications. The market of OSGi based COTS components is continuously growing. OSGi specific problems make it harder to validate such components. The absence of separate object spaces to isolate components may lead to inconsistencies when they are stopped. The platform cannot ensure that objects from a stopped component will no longer be referenced by active code (a problem referred by OSGi specification as stale references) leading to memory retention and inconsistencies (e.g., utilization of invalid cached data) that can introduce faults in the system. This paper classifies different patterns of stale references detailing them and presents techniques based on Aspect Oriented Programming for runtime detection of such problems. We also present a fail-stop mechanism on services to avoid propagation of incorrect results. These techniques have proven to be effective in a tool implementation that validated our study.

Describing Dynamism in Service Dependencies: Industrial Experience and Feedbacks

“…This would block the updating process. Debugging stale references is a timeconsuming task requiring a deep expertise in the OSGi™ platform [18].…”

Using fail-stop proxies for enhancing services isolation in the OSGi service platform

“…a provided service instance) will no longer be referenced. Although the OSGi platform provides events indicating the departure of services and bundles, if the service consumer code does not release correctly the object reference, this implies a problem referred in the OSGi platform as stale references is detailed in [6].…”

Developing Adaptable Components Using Dynamic Languages

“…The previous proxy is invalidated (i.e. new calls to its methods will fail since it is no longer valid), allowing to find stale references [16], if any. An interface withdrawal does not require proxy regeneration, since modifying the objectClass property associated with the service registration in OSGi is enough.…”

“…The OSGi specification, release 4, has introduced a model called Declarative Services (DS a.k.a SCR for Service Component Runtime) [16], largely based on ServiceBinder [8]. DS helps to address the management of dynamic connections to required services and the life cycle which is based on the presence or absence of the required mandatory services.…”