aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: Do we really need Quiesce support?
Date Sat, 14 Feb 2015 09:15:38 GMT
2015-02-13 22:56 GMT+01:00 David Bosschaert <david.bosschaert@gmail.com>:

> I think I understand the use-case now as well. The osgi-dev thread
> started by Christian [1] also provides valuable insight.
> If I can summarize the quiesce functionality it is aimed at preventing
> operations from failing. Rather than failing, you stop accepting
> requests, then perform some interruptive task such as applying an
> update and then you continue.
>

Agreed


>
> I'm wondering however, while this might prevent a certain form of
> failure, other forms of failure might still exist. Someone might
> accidentally unplug a network cable. A harddisk (or even raid array)
> crashes. There is a power outage. It's quite easy to come up with
> other examples. Even with quiesce support failure might still happen
> as the bundle doesn't accept requests any more and hence the caller
> might fail.
>

I don't think we should even think about using the quiesce api
in such a case.  The quiesce api is really to clean stop a bunch
of bundles.  This means that a user, or agent, decided to stop it.
In the case of an outage, the system must react to an error condition,
but this is usually already managed in most cases.
For example a JDBC connection will thrown an exception, and when
the application try to use it again, it will have to wait to establish a
new connection.
So I don't think we should even think about this problem, that's out
of the scope.

I can summarise the requirements:
  R1: we want a clean shutdown where inflight calls are correctly finished
  R2: stopped bundles should not perform any more work, as they should
            have clean up all their resources by the time they are stopped
  R3: we have a bigger problem when we consider a set of bundles to be
            stopped as an inflight call in one bundle may lead to new calls
in
            some service dependencies
  R4: we also need a way to have a fast shutdown

R4 could be removed, in which case, the logic to cleanly stop a
bundle could be done when the bundle is actually stopped (i.e. in the
BundleActivator#stop in case of pure osgi bundle or by intercepting the
STOPPING event in the case of an extender).
If R4 is kept, it means we need something like the QuiesceParticipant
that bundles or extenders could implement to perform a clean shutdown.
Another alternative would be to always do the logic when the bundle is
stopped, and using some kind of global flag.  The downside is that if you
use the same method, you loose the ability to perform a quick stop if
a clean stop is already running (the clean stop could take quite some time).

R3 means we need an API (it could be an OSGi service as in the quiesce
api, or some reusable code).
Given we're mostly talking about service dependencies, I think the code I
wrote in karaf4 could be really reused to order bundles correctly. I think
the current quiesce manager does not cover this use case correctly, but I
may be wrong.

Also, we need to consider other extenders such as servlets, and DS.
For blueprint, we already have some code and it's easily doable because
blueprint already has support for proxies.  DS does not have that and the
only way with the current code would rely on the user to add its own
synchronization to delay the deactivation of each component until calls are
finished.

Anyway, the current quiesce API is quite minimal and seems to fulfil the
problem to me.  The code may be improved obviously and we could
enhance other extenders to actually leverage it (felix scr, pax-web,
etc...).




>
> As Tim Diekmann suggested on the osgi-dev thread, to really be
> completely safe you need to build your safety on another level. It
> might be better to write your system such that it is ready for
> (occasional) failure and can handle that gracefully and correctly
> rather than trying to come up with solutions that might prevent some
> of those occasional failures, especially since it can never handle all
> of them.
>

As I said earlier, I don't see any relationship between performing a clean
shut down of bundles and reacting to any kind of system failure.  The
clean shut down is to be used when there's no outage and imho it does
not make any sense at all to use it in case of an outage.


>
> Just my 2c,
>
> David
>
> [1] https://mail.osgi.org/pipermail/osgi-dev/2015-February/004744.html
>
> On 13 February 2015 at 18:25, Christian Schneider
> <chris@die-schneider.net> wrote:
> > Many thanks for the explanations.
> >
> > For JPA I think I now understand what we need to achieve. As soon as a
> > persistence unit bundle is quiesced no new EMs should be created.
> > The opened EMs of the persistence bundle are closed when all calls that
> use
> > them are finished. Then when all those EMs are closed the quiesce
> > operation reports that it is finished.
> >
> > I hope this is stated correctly.
> >
> > Btw. the reason why I want to really understand this in detail is that I
> am
> > planning a bigger redesign of the jpa code. So I want to make sure I
> > understand the current requirements and
> > also try to slim them down wherever possible.
> >
> > Christian
> >
> >
> > On 13.02.2015 17:56, Jeremy Hughes wrote:
> >>
> >> 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.
> >> Jeremy
> >>
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > http://www.talend.com
> >
>

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