ServiceUnavailableException printed on peaberry bundle restart.

[mcculls]

Originally reported on Google Code with ID 7

The ImportManager thread started from within the peaberry bundle Activator 
tosses a ServuceUnavailableException when the bundle is restarted. You can 
reproduce this almost always if you restart the activator 2-3 times in 
fast succession.

I think the the sequence that causes this is:

1) zombie.interrupt() is called.
2) the thread manages to snatch a CachingServiceRegistry instance out of 
the Iterable<CachingServiceRegistry)
3) Activator.stop() completes and the BundleContext becomes invalid
4) the thread tries to call CachingServiceRegistry.flush()
5) Tather than complete cleanly it crashes with the attached exception.

I see this a minor/cosmetic problem. However it get's me on edje during 
testing to see a stack trace and have to remember this one is a good 
exception I can ignore.

I fixed this and everything seems to work fine. Because I don't have 
commit access I am attaching the fixed Activator to this issue. I have 
also made some refactorings to make the Activator a bit more Guicy :)

Reported by Rinsvind on 2008-10-08 09:35:43

---

• Attachment: peaberry.restart.txt
• Attachment: Activator.java

[mcculls]

Thanks, I'm still finishing unit tests for the new flush functionality and hadn't got
round to do stress tests. BTW the service unavailable exception is valid, because the
thread is trying to use a service which is no longer available, and the thread should
expect this (as OSGi services may go at any time *) and in this case ignore it.

I'll also take a look at your other changes and hope to commit this fix later today.

(* I might also add another decorator utility that provides a "no-op" service for
when no service is available - this could be used by clients when they don't want to
handle the service unavailable exception...)

Reported by mcculls on 2008-10-08 10:05:31

• Status changed: Accepted

[mcculls]

Yes all code should be ServiceUnavailableException-tollerant under the dynamic 
conditions of OSGi. This is the one little thing no ammount of smarts can hide from

the poor bundle developer :)

Nice idea to have an additional decorator. That reminds me of Felix' NullObject 
pattern. Here's something for your idea bag (in case you it ain't there already):

http://felix.apache.org/site/dependency-manager-background.html

http://felix.apache.org/site/dependency-manager-usage.html#DependencyManagerUsage-
Implementingtheservice

It sould be easy to generate NullObjects on the fly with ASM. Than some additional

EDSL method like "DynamicServiceBuilder.asOptional()" can be added to trigger this

behavior.

Reported by Rinsvind on 2008-10-08 11:23:55

[mcculls]

Reported by mcculls on 2008-10-16 07:21:48

• Status changed: Fixed

[mcculls]

Reported by mcculls on 2008-10-16 07:22:24

[mcculls]

Reported by mcculls on 2009-02-03 09:40:32

• Status changed: Verified