Building dynamic applications with OSGi services - Enterprise OSGi in Action - page 156

Setting timeouts
The default Blueprint timeout is five minutes, but it can be adjusted per bundle or per
reference. For example, the following update to the Inventory reference ensures that
method invocations never block for more than two seconds, even when no Inventory
service is available:

<reference
id="inventory"
interface="fancyfoods.food.Inventory"
timeout="2000" />
Timeouts can also be set for an entire bundle in the manifest by setting directives on
the symbolic name:

Bundle-SymbolicName: fancyfoods.persistence; blueprint.timeout:=2000
If the timeout is set to 0 , a service invocation will block indefinitely.

6.4.2 Multiplicity and optionality

Part of the power of Blueprint services is that you can easily tune how many instances
are injected (multiplicity), and what happens if none at all are available (optionality).

OPTIONAL SERVICE REFERENCES
When declaring a Blueprint service reference, one of the things you can do is declare
that it's optional:

<reference
id="specialOffer"
interface="fancyfoods.offers.SpecialOffer"
availability="optional"/>
This means that if no satisfactory service can be found, the Blueprint container will
still start up and initialize the rest of your beans. This is useful; you often don't want a
single missing service to be fatal. But what happens if you try to use an unsatisfied
optional service?

SERVICE DAMPING AND OPTIONAL REFERENCES
As it happens, after the Blueprint container has been initialized for a bundle, optional
services are indistinguishable from mandatory services. Even if the backing service
goes away—or was never there—any method invocation on the injected service
(which is a proxy, remember) will block until the service reappears or until a timeout
happens. Whether your service is optional or mandatory, you'll need to remember
that a timeout could occur and a ServiceUnavailableException could be thrown.
A service being unavailable is arguably much more likely if the service was optional
in the first place, and so using your optional services as if they were mandatory ser-
vices may lead to some long delays. How can you handle missing services gracefully?
One option is to set a short timeout and catch the ServiceUnavailableException. A
cleaner option is to use a reference listener to monitor the lifecycle of the service
(more on those in a moment). Alternatively, the sneakily lazy option is to use a refer-
ence list instead of a reference for your service.