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:11:33 GMT
2015-02-12 17:33 GMT+01:00 David Bosschaert <>:

> 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 disagree.  What is needed is a clean shutdown of bundles.
The only way to achieve that without taking control of the order in which
bundles are stopped would be by intercepting the ServiceEvent.UNREGISTERING
event and *blocking* the call.  Though the problem is that you still can't
make the difference between a clean shutdown and an "immediate" shutdown.

Saying that the extender should take care of the case where the database
goes away is correct, but not sufficient.  Obviously, the system needs to
take into account things like network connections going down.  But throwing
an exception to clients and rolling back all inflight transactions is just
not something you want when updating a bundle on a production system.

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

I agree.  But if you think the use case I outlined are invalid, we're
starting on the wrong foot ;-)

> Best regards,
> David
> On 12 February 2015 at 16:20, Christian Schneider
> <> 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
> >
> >
> > Open Source Architect
> >
> >

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