aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Hughes <>
Subject Re: Do we really need Quiesce support?
Date Fri, 13 Feb 2015 16:56:12 GMT
I've been digging around in my memory. The Quiesce capability is a like a
soft-stop. It's a generic capability that is enforced differently depending
on the context. It's more normal for an extender to implement the
QuiesceParticipant rather than an individual bundle. In the case of the
Blueprint extender, in flight service calls are allowed to finish - they're
counted in and counted out - and no new calls are allowed. When there are
no in flight service calls, the bundle is told to stop. The Blueprint
bundle itself doesn't know this is happening which is a key design point.
In the case of JPA, I believe the extender ensures no new Entity Managers
are created - so similar to the Blueprint case. But it's been a while since
I looked at this.

Hope that helps.

On 13 February 2015 at 11:43, Guillaume Nodet <> wrote:

> 2015-02-13 12:23 GMT+01:00 Christian Schneider <>:
> > On 13.02.2015 11:58, Guillaume Nodet wrote:
> >
> >>
> >>
> >> Your example expects a simple restart of the service, I'm talking about
> an
> >> update/refresh of the bundle.
> >> But even restarting the service, if the service is an EntityManager,
> that
> >> does not work afaik : you can't just switch it in the middle of your
> >> processing (what you've already done with the JDBC connection in the
> >> context of your transaction can't be propagated to a new connection).
> >>
> > You are right about a service that provides EntityManger instances. The
> > problem here is that the service is not really stateless which makes it
> > much harder to manage.
> >
> You could also think about a camel component you want to update.  In such a
> case, you want the routes to cleanly shutdown before actually updating the
> component.
> > For a normal EntityManagerFactory (like provided by jpa.container) this
> > should not apply as the EntityManager is under control of the client
> bundle.
> >
> > In case of jpa.container.context there probably is a problem. The service
> > holds instances of EntityManager. So if this bundle is updated I would
> > expect it to close
> > all EntityManager instances. So the state would be lost. This is a very
> > special case though and I dont think it would warant the Quiesce support
> > all for itself.
> > After all updating aries jpa is rather seldom for a customer compared to
> > updating their own bundles. So I think it should be ok to handle this
> case
> > manually in a special way.
> >
> > For updates of user bundles there should be no issue I think.
> >
> This problem is a general problem, think about CXF services, camel routes,
> etc...
> It may be possible to partially get rid of the quiesce api if all bundles
> would always perform a clean shutdown when being stopped.  That's actually
> what camel does afaik.
> If shutting down a blueprint bundle or an jpa container would wait for all
> calls to be finished before actually shutting down, it may help a lot.
> Though even doing that would not really be sufficient, as you can't track
> inside an individual bundle, the fact that a service is "still" in use,
> even without being currently called.
> I.e. if you have a service which performs several operations on the entity
> manager, you could delay the stop of the entity manager until one call is
> finished, but what you really want is coordination so that the entity
> manager it stopped until the bundle using the entity manager is completely
> done.  For that, you need cooperation of bundles, and the OSGi api does not
> really provide anything afaik.
> There may be alternatives though, as the service dependencies can be
> introspected from the outside.
> In karaf 4, when we need to refresh bundles, we do an orderly shut down of
> bundles according to service dependencies.  In the case above, we would
> first shut down the client bundle, then the JPA entity manager. If each
> bundle performs a clean shut down, it may be sufficient and we could get
> rid of the quiesce api, but not of the code which tracks calls, that's
> needed to perform the clean shut down.
> >
> > Btw. I am not yet sure what a refresh in OSGi actually does. Let us
> assume
> > we refresh a bundle that provides a package that is imported by other
> > bundles. Will these bundles also be refreshed then?
> >
> Yes
> > If not then I think  these bundles will not see the new package. So in
> > case the package contains a service interface they will not see the new
> > service. As this seems to work in practice (at least in karaf) I assume
> > that in karaf the
> > client bundles are also refreshed. Is that correct?
> >
> If the interface containing the bundle is refreshed, the bundle using that
> interface is refreshed too.  If the api is packaged as a separate bundle
> and you update the implementation, the client bundle won't be refreshed.
> >
> > Btw. this reminds me of this issue
> > jira/browse/ARIES-1270 .
> > There we refresh a persistence unit bundle. After this the client bundle
> > and the EntityManagerFactory saw different classes for the Entities.
> > I do not think this is Quiesce related though. If you have any ideas
> about
> > that would be great as I do not seem to find any solution.
> >
> >  The doc mentions "threads started by this bundle".
> >>>
> >>> If a bundle B calls a service from bundle A then the thread is not
> >>> started
> >>> by bundle A. So it should be fine that this thread keeps running
> >>> even when the Activator.stop was called.
> >>>
> >>>  Here's what the spec says for services (section 5.7, osgi core 6):
> the
> >> behaviour of a a service object that becomes unregistered is undefined.
> >> Such service objects may continue to work properly or throw an exception
> >> at
> >> their discretion.  Imho, in a production environment, you don't really
> >> want
> >> to rely on an undefined behavior.  And if the service throws an
> exception,
> >> it's not a clean shutdown anymore.
> >>
> > I would interpret this part of the spec ("at their discretion") that the
> > service implementor is free to either continue working or throw an
> > exception.
> > So if he does not do anything special it should be fine.
> >
> >
> > Christian
> >
> >
> > --
> > Christian Schneider
> >
> >
> > Open Source Architect
> >
> >
> >

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