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

Figure 6.8 If the persistence bundle is stopped, the Blueprint container automatically makes the cheese
special offer unavailable and removes it from the reference list in the offer aggregator. Subsequent re-
quests won't see the cheese offer.
Timeouts
What happens if an attempt is made to use an injected service after it goes away? Noth-
ing—literally! If a method is invoked on the service proxy, the proxy will block until a
suitable service becomes available or until a timeout occurs. On timeout, a Service-
UnavailableException will be thrown.
In practice, timeouts don't occur often, because the automatic unregistration of
chained dependencies eliminates most opportunities to use nonexistent services. You
can see this behavior in the Fancy Foods application if you try hard, but with a little
tweaking you can make it happen much more often. What's required is a bit of sur-
gery so that you can stop a service before it's been used, but after any services that
depend on it have been invoked. What you're trying to simulate here is a minor con-
currency disaster, rather than normal operation.
The code you need to modify is in the cheese department of your application.
You'll modify the getOfferFood() method on the DesperateCheeseOffer to insert a
pause so that you can reliably stop the persistence bundle in the middle of the
method execution:
public Food getOfferFood() {
long start = System.currentTimeMillis();
System.out.println("INVOKED, PAUSING, STOP THAT BUNDLE!");
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
}
System.out.println("RESUMING after "
+ (System.currentTimeMillis() - start) + " ms");
List<Food> cheeses =
inventory.getFoodsWhoseNameContains("cheese", 1);