On 13.02.2015 17:40, David Jencks wrote:
I don't know what the quiesce service is supposed to do either. However I take
issue with one statement below… hopefully I misunderstood what you mean:
- bundleA stops which should not affect inflight processing inside bundle A
????????????
Lets suppose A's services are implemented as DS components. Stopping the bundle will
deactivate and unregister all the services. Unless someone has taken care (probably with
a read-write lock on all the DS event and lifecycle methods and all the service
operations, something I have never ever seen, and would violate the "quick
shutdown" expectation) that all the work being done on worker threads has completed
before deactivate is called, worker threads will continue to operate in the deactivate
component. They aren't going to get very far because all the references have been
removed.
So I rather suspect the quiesce service might be intended to deal with this
kind of problem, although I have no idea how.
For DS I am not sure what it does when it shuts down a component. If it
simply deregisters the component then its injected service objects would
still be present. So the inflight call might still work. I am not sure
about this though.
For blueprint I am also not sure if the inject proxies for services
would still work. Probably not.
So yes you are right. In the general case inflight calls might indeed be
disturbed. In this case I wonder how this is expected to work in OSGi
without an additional API.
I also just discussed with Guillaume on IRC that at least after
uninstall even the classloader of the bundle might stop working.
I asked about these cases in the osgi dev list to see if plain OSGi has
some answers for these problems.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
