On 12.02.2015 21:41, Guillaume Nodet wrote:
Quiescing a single bundle does not make sense I think. Quiescing
obviously means you want to stop a bunch of bundles. In this case, if
you want to actually stop bundle A, you also need to stop all bundles
using services from A, so that would include B.
Why would I want to stop the other bundles? The situation that a service
is going away is a normal thing in OSGi and the frameworks cover this
situation.
There are two cases:
1. Dynamic systems like DS
All components using Services from A in a mandatory fashion will stop
automatically. So no problem here.
2. Systems using damping like blueprint
Blueprint will block calls to Services offered by A if there is no
alternative service. This also seems to be fine for me. The calls will
time out after some time and the callers will react according to their
error handling functionality.
So I do not see the need for anything better than what OSGi already
offers for this use case.
This means that in order to stop A, I think you want to quiesce A and
B. One problem with blueprint, and it may be an implementation
problem, is the following. I just made a test with the
blueprint-testquiescebundle which exposes a simple bean with a sleep
method through blueprint. If I call it with a long sleep, and I
concurrently stop the bundle, the bean will continue executing while
the bundle is already stopped. That's quite bad actually.
I think it is absolutely fine that threads of a bundle that stops or is
even uninstalled continue to run. We might want to interrupt them so a
sleep returns earlier but even if the sleep continues I do not see an
immediate problem. It would just prevent the classloader from cleaning
up the bundle classses for some time. Btw. I think having such a long
sleep is an implementation problem that OSGi does not need to fix.
I think the quiesce participant for blueprint aims to work around this
problem by making sure all calls to a service exposed using blueprint
will cause a delay in stopping the bundle. This can be worked around
by adding a destroy method to the bundle and synchronise all public
methods. It could also be done in a smarter way by adding a read/write
lock instead. Anyway, I'm not sure if that's the real problem, but the
blueprint quiesce participant actually does that.
Thanks for describing this. I think the main problem with Quiesce is
that almost no one understands what problems it solves and if the
current solution actually solves these problems.
So I think what we need is to take step back and describe what actual
problems would occur without Quiesce and what Quiesce does to solve
them. Only then we will be able to maintain the code and to improve it.
The current status is that we have a proprietary API with no
documentation anywhere and very little understanding by at least the
active devs. So I hope some people from IBM can step up and help us to
better understand this.
I am pretty sure the current situation will lead to very bad quality of
the code around Quiesce in mid term as people will either avoid to
modify this code at all or the modifications will be wrong because of
bad understanding of the design and the issues to solve.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
