aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Do we really need Quiesce support?
Date Thu, 12 Feb 2015 11:21:56 GMT
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?

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
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


Mime
View raw message