You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by Martin Lichtin <li...@yahoo.com> on 2012/08/13 10:14:47 UTC
Quiesce support for Blueprint
Hi
At Karaf startup (in a Pax-Exam test) I see the following:
2012-08-13 10:05:28,974 | INFO | FelixStartLevel | BlueprintExtender | 9 - org.apache.aries.blueprint - 0.3.2 | No quiesce support is available, so blueprint components will not participate in quiesce operations
Ist this anything I should worry about?
Quiescing sounds great, so ideally I'd like to use this feature.
Martin
Re: Quiesce support for Blueprint
Posted by David Bosschaert <da...@gmail.com>.
Thanks for explaining, Tim! Yes, if you have destroy logic for your
service you need to ensure that this only executed once the last
consumer is done.
It would still be good if someone could do a little writeup on the
Aries website of the quiesce functionality just to document it...
Cheers,
David
On 15 August 2012 10:18, Timothy Ward <ti...@apache.org> wrote:
> Hi David,
>
> There are a couple of problems with the scenario you describe.
>
> Blurprint beans can have destroy methods, and other behaviours, that are
> affected by the blueprint container being stopped. If a consumer of a
> blueprint service is actively making a call into it when the blueprint
> container is being stopped then this leads to an unpleasant race condition.
> The service method call may fail unpleasantly as dependent services are
> unset half way, or beans are destroyed.
>
> This race condition can be an issue even when a new service is already
> available if the client does not eagerly switch to the new implementation
> (the default behaviour for blueprint service references).
>
> The quiesce support is designed to avoid these problems by unregistering the
> blueprint services, but not releasing the service references or destroying
> beans until all client method calls complete executing.
>
> Tim
>
> It relies upon the client eagerly switching to the new service.
>
>> From: david.bosschaert@gmail.com
>> Date: Mon, 13 Aug 2012 11:40:15 +0100
>> Subject: Re: Quiesce support for Blueprint
>
>> To: user@aries.apache.org
>>
>> Hi Tim,
>>
>> Sounds interesting, is there a technical document available somewhere
>> that describes a bit more in details how the Quiesce stuff works? I
>> couldn't find it on the Aries wiki.
>>
>> Specifically what does Quiesce add that ordinary OSGi services don't
>> have? I mean, I can update a bundle without interrupting service with
>> plain OSGi services by installing the updated bundle with the updated
>> service alongside the old bundle first then then take away the old
>> bundle.
>>
>> Cheers,
>>
>> David
>>
>> On 13 August 2012 11:24, Timothy Ward <ti...@apache.org> wrote:
>> > Hi Martin,
>> >
>> > Quiesce support is an optional feature for a number of Aries components.
>> > In
>> > order to use it you need to install the Quiesce API and Quiesce Manager.
>> > You
>> > can then use the Quiesce service to shut down your blueprint bundles
>> > cleanly
>> > even when they are still receiving requests. This allows you to do cool
>> > things like "hot updating" you bundles without interrupting service.
>> > Usually
>> > you would implement this as part of a custom application manager or
>> > installation service.
>> >
>> > I hope that helps!
>> >
>> > Tim
>> >
>> > ________________________________
>> > Date: Mon, 13 Aug 2012 01:14:47 -0700
>> > From: lichtin@yahoo.com
>> > Subject: Quiesce support for Blueprint
>> > To: user@aries.apache.org
>> >
>> >
>> > Hi
>> >
>> > At Karaf startup (in a Pax-Exam test) I see the following:
>> >
>> > 2012-08-13 10:05:28,974 | INFO | FelixStartLevel | BlueprintExtender | 9
>> > -
>> > org.apache.aries.blueprint - 0.3.2 | No quiesce support is available, so
>> > blueprint components will not participate in quiesce operations
>> >
>> > Ist this anything I should worry about?
>> > Quiescing sounds great, so ideally I'd like to use this feature.
>> >
>> > Martin
RE: Quiesce support for Blueprint
Posted by Timothy Ward <ti...@apache.org>.
Hi David,
There are a couple of problems with the scenario you describe.
Blurprint beans can have destroy methods, and other behaviours, that are affected by the blueprint container being stopped. If a consumer of a blueprint service is actively making a call into it when the blueprint container is being stopped then this leads to an unpleasant race condition. The service method call may fail unpleasantly as dependent services are unset half way, or beans are destroyed.
This race condition can be an issue even when a new service is already available if the client does not eagerly switch to the new implementation (the default behaviour for blueprint service references).
The quiesce support is designed to avoid these problems by unregistering the blueprint services, but not releasing the service references or destroying beans until all client method calls complete executing.
Tim
It relies upon the client eagerly switching to the new service.
> From: david.bosschaert@gmail.com
> Date: Mon, 13 Aug 2012 11:40:15 +0100
> Subject: Re: Quiesce support for Blueprint
> To: user@aries.apache.org
>
> Hi Tim,
>
> Sounds interesting, is there a technical document available somewhere
> that describes a bit more in details how the Quiesce stuff works? I
> couldn't find it on the Aries wiki.
>
> Specifically what does Quiesce add that ordinary OSGi services don't
> have? I mean, I can update a bundle without interrupting service with
> plain OSGi services by installing the updated bundle with the updated
> service alongside the old bundle first then then take away the old
> bundle.
>
> Cheers,
>
> David
>
> On 13 August 2012 11:24, Timothy Ward <ti...@apache.org> wrote:
> > Hi Martin,
> >
> > Quiesce support is an optional feature for a number of Aries components. In
> > order to use it you need to install the Quiesce API and Quiesce Manager. You
> > can then use the Quiesce service to shut down your blueprint bundles cleanly
> > even when they are still receiving requests. This allows you to do cool
> > things like "hot updating" you bundles without interrupting service. Usually
> > you would implement this as part of a custom application manager or
> > installation service.
> >
> > I hope that helps!
> >
> > Tim
> >
> > ________________________________
> > Date: Mon, 13 Aug 2012 01:14:47 -0700
> > From: lichtin@yahoo.com
> > Subject: Quiesce support for Blueprint
> > To: user@aries.apache.org
> >
> >
> > Hi
> >
> > At Karaf startup (in a Pax-Exam test) I see the following:
> >
> > 2012-08-13 10:05:28,974 | INFO | FelixStartLevel | BlueprintExtender | 9 -
> > org.apache.aries.blueprint - 0.3.2 | No quiesce support is available, so
> > blueprint components will not participate in quiesce operations
> >
> > Ist this anything I should worry about?
> > Quiescing sounds great, so ideally I'd like to use this feature.
> >
> > Martin
Re: Quiesce support for Blueprint
Posted by David Bosschaert <da...@gmail.com>.
Hi Tim,
Sounds interesting, is there a technical document available somewhere
that describes a bit more in details how the Quiesce stuff works? I
couldn't find it on the Aries wiki.
Specifically what does Quiesce add that ordinary OSGi services don't
have? I mean, I can update a bundle without interrupting service with
plain OSGi services by installing the updated bundle with the updated
service alongside the old bundle first then then take away the old
bundle.
Cheers,
David
On 13 August 2012 11:24, Timothy Ward <ti...@apache.org> wrote:
> Hi Martin,
>
> Quiesce support is an optional feature for a number of Aries components. In
> order to use it you need to install the Quiesce API and Quiesce Manager. You
> can then use the Quiesce service to shut down your blueprint bundles cleanly
> even when they are still receiving requests. This allows you to do cool
> things like "hot updating" you bundles without interrupting service. Usually
> you would implement this as part of a custom application manager or
> installation service.
>
> I hope that helps!
>
> Tim
>
> ________________________________
> Date: Mon, 13 Aug 2012 01:14:47 -0700
> From: lichtin@yahoo.com
> Subject: Quiesce support for Blueprint
> To: user@aries.apache.org
>
>
> Hi
>
> At Karaf startup (in a Pax-Exam test) I see the following:
>
> 2012-08-13 10:05:28,974 | INFO | FelixStartLevel | BlueprintExtender | 9 -
> org.apache.aries.blueprint - 0.3.2 | No quiesce support is available, so
> blueprint components will not participate in quiesce operations
>
> Ist this anything I should worry about?
> Quiescing sounds great, so ideally I'd like to use this feature.
>
> Martin
RE: Quiesce support for Blueprint
Posted by Timothy Ward <ti...@apache.org>.
Hi Martin,
Quiesce support is an optional feature for a number of Aries components. In order to use it you need to install the Quiesce API and Quiesce Manager. You can then use the Quiesce service to shut down your blueprint bundles cleanly even when they are still receiving requests. This allows you to do cool things like "hot updating" you bundles without interrupting service. Usually you would implement this as part of a custom application manager or installation service.
I hope that helps!
Tim
Date: Mon, 13 Aug 2012 01:14:47 -0700
From: lichtin@yahoo.com
Subject: Quiesce support for Blueprint
To: user@aries.apache.org
Hi
At Karaf startup (in a Pax-Exam test) I see the following:
2012-08-13 10:05:28,974 | INFO | FelixStartLevel | BlueprintExtender | 9 - org.apache.aries.blueprint - 0.3.2 | No quiesce support is available, so blueprint components will not participate in quiesce operations
Ist this anything I should worry about?Quiescing sounds great, so ideally I'd like to use this feature.
Martin