aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <david.bosscha...@gmail.com>
Subject Re: Do we really need Quiesce support?
Date Thu, 12 Feb 2015 16:33:09 GMT
I would definitely be interested in seeing alternatives. I still don't
fully understand the use-case to be honest. Looking at the database
example from Guillaume above, I don't see why the bundles need to be
taken down in a controlled manner. Let's say the database bundle is
stopped before the CXF bundle, then surely the CXF bundle can react to
that in the appropriate manner. In OSGi services are dynamic, they can
come and go at any point in time. If that CXF bundle has a dependency
on the database service it should handle the case when that database
service goes away, either by using DS, Blueprint or something
lower-level like a ServiceTracker or ServiceListener. The service
might re-appear at a later point in time and again the using bundle
should be able to deal with that.

I think the code cleanup estimate from Christian is impressive. If we
have an alternative to compare the Quiesce functionality with I think
this would be interesting. I don't mean to say remove the Quiesce
support, but I think it would be healthy to have the discussion about
alternatives and compare options.

Best regards,

David

On 12 February 2015 at 16:20, Christian Schneider
<chris@die-schneider.net> wrote:
> I just checked the diff of my changes when removing Quiesce. We would be
> able to remove ~20 classes and 1500 lines of code.
> So I think it would be worth the time to check if we can achieve the same
> with an alternative solution.
>
> Apart from complexity and code size my big problem with the way Quiesce
> works in aries jpa is that it creates a proxy for the EMF and the EM with
> artificial methods to shut it down.
> I think that is not a good idea at all. With the proxied EMF we also shut
> down EMs that other bundles created. This can lead to problems in these
> bundles as they are probably not aware of this.
>
> I think we should rather track the EMs we create ourself (mainly in the jpa
> blueprint code) and close these when the quiesce happens.
>
> Christian
>
> On 12.02.2015 11:25, Graham Charters wrote:
>>
>> Hi David/Christian,
>>
>> Here is what Mark wrote, that didn't make it:
>>
>> "Quiesce is about stopping a bundle gracefully prior to its
>> uninstallation,
>> which is why we've had no need to implement a 'restart' capability. We
>> currently use Apache Aries quiesce within IBM WebSphere Application
>> Server.
>> It's used in a scenario where an administrator is replacing some of the
>> bundles within a running application. The code has been in use in that
>> product for some years now so yes, I'm sorry but we do have a definite
>> need
>> for the facility."
>>
>> Essentially, we use it to notify containers/extenders of bundles that are
>> about to be uninstalled (prior to that actually being done) so they can
>> perform house-keeping ahead of uninstallation being kicked off.
>>
>> Regards, Graham.
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>

Mime
View raw message