aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <>
Subject Re: Do we really need Quiesce support?
Date Fri, 13 Feb 2015 21:56:08 GMT
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.

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.

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.

Just my 2c,



On 13 February 2015 at 18:25, Christian Schneider
<> 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
> Open Source Architect

View raw message