Service Coroner: a Diagnostic Tool for Locating Osgi Stale References
Total Page：16
File Type：pdf, Size：1020Kb
Service Coroner: A Diagnostic Tool for Locating OSGi Stale References Kiev Gama and Didier Donsez University of Grenoble, LIG laboratory, ADELE team {firstname.lastname}@imag.fr Abstract Moreover, the OSGi specification applies service- The OSGi Services Platform provides a framework oriented architecture principles to Java application for the dynamic deployment of Java-based design. The concept of service is important to decouple applications. It allows to install, to activate, to update the application modules in order to dynamically and to uninstall application modules without the need substitute or update individual modules without to restart the host Java Virtual Machine. However, the affecting the entire system. mishandling of such OSGi dynamics may result in a The OSGi has proved to be successful in embedded problem described in the OSGi specification as Stale systems. Its adoption in the software industry is References, which happen when services from continuously growing as more applications tend to take uninstalled modules are still referenced by active code. advantage of its pluggable architecture. One of the well It may lead to inconsistencies in application’s known cases is the Eclipse project [2] that since behavior, state and memory. Currently, there are no version 3.0 has migrated to the OSGi platform. A new tools available to address this issue. This paper trend in desktop applications [2] and server presents a diagnostics tool named ServiceCoroner that middlewares [3] (i.e., JOnAS, Weblogic, WebSphere) detects such problems. It helps developers and shows the growing adoption of OSGi as a modular administrators diagnose OSGi applications running layer for either commercial or open-source Java-based either in production or test environments. We have products. validated this tool on two open source applications Programming a modularized application that targets that run on OSGi: a JavaEE application server and a OSGi is a task that is apparently easy but developers multi-protocol instant messenger application. The must be aware of some particularities. It is critical to results of the experiments show stale references in correctly handle framework events such as arrival those applications. (registration) and departure (unregistration) of services and bundles. Most of the time, application developers that are not experienced with OSGi dynamics provide 1. Introduction code that may retain service references even when the providing bundles are gone. The OSGi R4 specification The OSGi [1] framework introduced the concept of refers to this problem as stale references . Identifying module system that was missing in the Java platform. stale references is not easy since current Java This concept tackles the problem of the “Classpath diagnostic tools do not handle this OSGi specific hell” encountered when applications are deployed problem. (installed or updated) on production sites (i.e., end-user This paper presents the results of an experiment PCs or host servers). Applications can take advantage made with a custom built tool which allows the analysis of a “hot deploy” capability, where modules (called and detection of stale references. The objective of the bundles in OSGi nomenclature) can be added, updated tool is not to solve the stale references problem, but to or removed without restarting the JVM. In addition, identify it and help developers and administrators of each bundle is provided with its own class loader. This OSGi based applications ensure that bundles provide provides various advantages including the possibility of behavior well suited to OSGi dynamics. The tool was having independent versions of the same class, and validated with the analysis of two open source allowing the unloading of classes when a module is applications constructed on top of OSGi: updated or uninstalled. JOnAS 5.0.1 [4] and SIP Communicator [5], both of which have presented stale references after the update of some bundles. The remainder of this paper is structured in the that the garbage collection will take place correctly and following order: Section 2 details OSGi and the stale that no bundle will utilize inconsistent services. references problem. Section 3 describes our tool, Figures 1 through 3 illustrate a common scenario of ServiceCoroner, and the techniques used to develop it. life cycle events that result in a stale reference being In section 4, the analysis of two OSGi applications is kept. In Figure 1 normal interaction between the detailed. Section 5 presents related work, and at last service provider and the service requester can be seen conclusions and future work are presented in section 6. on Bundles 1 and 2, respectively. Bundle 2 consumes a service whose implementation is provided by an 2. OSGi and the Stale References Problem instance of the class A from Bundle 1. If Bundle 1 is stopped, the framework will The OSGi framework provides each bundle with a automatically notify the unregistering of all services BundleContext object that gives access to the provided by that bundle. In our scenario, Bundle 2 is underlying framework. A bundle can register and supposed to release references to the service instance retrieve services through the BundleContext. In order of class A upon the unregistration of A’s corresponding to retrieve a service instance in OSGi it is first service reference. This results in having no references necessary to know its ServiceReference , which is towards objects of Bundle 1, permitting these objects service metadata that informs what bundle provides the to be collected by the JVM. service, what are the service properties, and so forth. However, Figure 2 shows that this procedure was The BundleContext provides a getServiceReference not performed by Bundle 2, which keeps holding a method that takes the name of the service interface and reference to a service instance from a stopped bundle an optional property filter. (Bundle 1). It shows that Bundle 2 did not handle the A bundle that provides a service may choose to departure of the service reference that provides the A directly provide the service instance 1 or to provide a service instance. Bundle 2 is still able to perform ServiceFactory that will be responsible of creating method calls on the object A that possibly can lead to service instances. The ServiceFactory makes it possible inconsistent information or to an inconsistent state to provide an individual service instance per client since such method calls are being made on an object bundle. That is, if two bundles request the same service from a stopped bundle. For example, network they will get different instances of the very same type. connections or file streams could have been closed by After being loaded by OSGi, each bundle will have the stopped bundle, causing errors on the object A. an individual class loader to load resources (e.g., The retention of the service instance will prevent the images, text files) and classes provided by the bundle. A object of being garbage collected. As a consequence, This, combined with a class import and export policy, A’s class loader and all class types (java.lang.Class) it gives a certain level of isolation between bundles. This has loaded will also hang in memory. mechanism provides an additional namespace level In the continuation of the described scenario, the making it possible to have multiple versions of classes Bundle 1 has been updated during runtime. A new class with identical absolute names but provided by different loader has been assigned to that bundle, and a new bundles (note that this is not related with the instance of A (now from a different class loader) has ServiceFactory described before). been registered. Figure 3 shows that Bundle 2 kept using the stale reference and did not take into 2.2. The Stale References Problem consideration the arrival of the new service provided by the updated Bundle 1. Although OSGi provides individual class loaders In the described scenario the objects from old per bundle, bundles are not completely isolated from Bundle 1 (the service instance A v1.0, its class loader each other. One bundle may use a service that is and all java.lang.Class instances loaded by that class provided by another, and consequently originated from loader) will only be eligible to garbage collection if a different class loader. Whenever a bundle becomes Bundle 2 is stopped. However, if Bundle 2 is restarted unavailable all other bundles that use its classes must the same situation is likely to happen again upon the release all references to objects provided by the same sequence of events. departed bundle. This procedure is necessary to ensure This is not only limited to bundle updates. If, for example, a bundle provider of a given service instead 1 of updated is just stopped or uninstalled, it can never For the sake of clarity this paper refers to service reference as the ServiceReference object, and service instance as an be released from memory if a similar situation as in instance provided by the BundleContext via the Figure 1 happens. getService(ServiceReference) method. Bundles isolation is compromised by the bad handling of service departure. The OSGi specification indicates practices to minimize the problems but they still are error prone. An alternative to avoid such problems is to utilize mechanisms that provide transparent handling of service location, like the ServiceTracker. However, in that approach, clients can still keep references to service instances no matter how these references were retrieved. In addition to transparent location handling, other mechanisms like OSGi declarative services, Service Binder [14], iPOJO [6] and Spring Dynamic Modules [15] deal seamlessly with the releasing of service instances and service references upon service unregistration. Figure 1. Normal scenario These last two options are the ideal way to provide a more complete handling of service dynamics, consequently avoiding stale references. On the other hand, stale references can still be found in other patterns.