aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: Do we really need Quiesce support?
Date Thu, 12 Feb 2015 20:41:21 GMT
2015-02-12 12:21 GMT+01:00 Christian Schneider <>:

> I think this is in part because of the service damping in blueprint.
> Blueprint will not shut down a service if a service it depends on goes away.
> If you have a more reactive framework like DS it would not happen. If you
> remove the DataSource then any DS component using it will also go down.
> Besides I am not sure how quiesce can solve that? You still have to
> quiesce the correct bundle.
> Imagine bundle A contains the bean with JPA access and bundle B contains
> the CXF service which uses the service from B.
> If you quiesce bundle A then bundle B will still provide the CXF service
> but does not work anymore (when using blueprint).
> It would have the same effect to simple stop bundle A. Maybe I am missing
> something but how does the Quiesce API support this better?

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.
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
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 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.

> Christian
> On 12.02.2015 12:06, Guillaume Nodet wrote:
>> I think I actually do understand the need.
>> When you want to stop a bunch of bundles, you can choose to stop them in a
>> random order, or in a smart way.
>> At the end the result may not be the same.
>> Let me take an example: a cxf service which accesses a database.
>> If you choose a random order, you may shut down the database access
>> (DataSource in osgi for example), before shutting down the cxf service.
>> The effect will be that you will make inflight requests to fail.
>> The correct way would be to shut down the cxf service in a clean way, i.e.
>> do not accept any more incoming requests, and wait for inflight requests
>> to
>> be finished, then shut down the cxf service, then shutdown the jdbc
>> factory.
>> This is somewhat what the bluprint extender try to do when you shutdown
>> the
>> extender itself, but if you bundles encompass multiple different
>> extenders,
>> they need to cooperate in a smarter way.  This could also apply to CXF
>> services, camel routes, etc...
> --
> Christian Schneider
> Open Source Architect

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message