Hi, I have seen a similar issue before. I actually don’t think that the bean you have referenced directly creates that, but I bet you have a service reference (e.g. for cassandraSession) somewhere in your blueprint descriptor. A service reference does not resolve into the original service object, but into a blueprint proxy object that manages the actual service reference. If you stop the blueprint bundle, the blueprint context will be destroyed (and the dependency graph is usually considered in the order of destruction), which also includes the proxy object for the service reference. If any object leaks out of your blueprint context (e.g. by passing it to some other service or by storing it in a thread context), you will not notice this for regular beans (because they are actually pojos and live as long as they are referenced), but service proxies become broken as soon as the blueprint container is destroyed and you will get this exception on any invocation of the proxy.
In my case we were referencing a DataSource as a service and passing it to a Spring transaction manager. That stored the transaction synchronization in a thread local hash map using the DataSource (which is then a blueprint proxy) as the key. If the blueprint bundle is stopped why the transacted thread is still running the transaction manager cannot remove the transaction entry from the has map anymore because the DataStore proxy object will get you "the blueprint container is being or has been destroyed" even when calling the hashCode() and equals() method which is required to remove something from the hash map. In short: When you see that error you should probably look which blueprint service proxies are involved and how they leak out of the context of your blueprint container. The stack trace of the exception might help you with that (who is trying to call the method that is throwing this exception). Best regards Stephan From: Harrison Tarr <harri...@heliossoftware.com> Sent: Mittwoch, 25. März 2020 19:44 To: user@karaf.apache.org Subject: Re: ServiceUnavailableException after bundle restart Oh one more piece of info I just thought to add that I think is relevant: the serviceunavailableexception is caused by "the blueprint container is being or has been destroyed". On Wed, Mar 25, 2020 at 11:31 AM Harrison Tarr <harri...@heliossoftware.com<mailto:harri...@heliossoftware.com>> wrote: Hi all, I'm running into a weird problem with my blueprint bundle in Karaf. I have bundle A that exports a service (it uses a factory-method vs a constructor, as it's a third party interface ( <bean id="dataSession" class="com.datastax.driver.core.Session" factory-method="dataSession" factory-ref="cassandraSession"/> ) When I restart bundle B that uses the service, some of the calls that use the session throw a ServiceUnavailableException (but not all?) In any case, shouldn't bundle B remake all the necessary service references? Any ideas what could be causing this? The service is definitely still available. I'm happy to provide more info if it's necessary, I'm hoping maybe this is an easy fix though! Regards, Harrison
