Declarative Services: Delayed Components

Posted by Felix Meschberger JAN 12, 2010

Posted in component, declarative services, delayed component, osgi and scr Comments 4

Declarative Services: Delayed Components

The OSGi Declarative services specification defines three types of components:

Immediate Components are immediately created when the providing bundle is started and may or may not provide services
Delayed Components provide services but are only created when used by a service consumer.
Factory Components are created on demand by calling the ComponentFactory.newInstance(Dictionary) method of the Component Factory service registered for the component.

This blog is about a special behaviour of delayed components which may seem unexpected in the first place: Delayed components are created (activated) on-demand (when they are first requested) and have to be deleted (deactivated) as soon as there is no user any longer (Chapter 112.5.4, Delayed Component, in the Compendium Spec; see also FELIX-1825)

The intent of this behaviour is to reduce the system (or bundle) startup time in that delayed components are only instantiated when really used. In addition memory consumption may be reduced at times when the service is not used. The drawback is, that the service is activated and deactivated if there is a single consumer which uses the service for short periods of times only. An example of such an oft used service is an OSGi EventHandler service, which is got by the Event Admin service when ever an event must be delivered and released after the delivery.

How does a Component become a delayed component ?

By default a component providing a service is a delayed component unless the component is explicitly declared as an immediate component. If you are using the Apache Felix Maven SCR plugin, a component is (by default) delayed if the @scr.service tag is used. Thus the above activation and deactivation rules apply. To turn a service component into an immediate component, you have to set the immediate attribute to, as in :

 @scr.component immediate="true"

Shall I change all my components to be immediate components ?

The short answer is: It depends.

Here are some general rules of thumb:

If your service can be expected to be immediately used and not released until system shutdown, defining the component as delayed does not make much sense. In this case, it is probably better to explicitly define the component as immediate. An example of such a component is a Servlet service in Sling, which is immediately used by the Sling Servlet Registry.
If your service is in fact a service factory (using the servicefactory attribute, you cannot declare the component immediate, because service factory components are always delayed
If your component is used a lot for short periods of time, you should probably define your service as an immediate component. An example of such a service is an OSGi EventHandler service.
If you want to maintain state in your component and make that state available to clients by registering a service, the component should be defined as immediate. An example of such a service might be statistics provider, which gathers statistics and provides them through its service API.
If your component is only seldom used it would be best to define it as a delayed component. An example of such a component in Communiqué 5 might be a workflow step service, which implements very specific behaviour.