aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Do we really need Quiesce support?
Date Fri, 13 Feb 2015 08:04:32 GMT
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 

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 Schneider

Open Source Architect

View raw message