Re: Annoyance during update of bundles

[Felix Meschberger <fm...@gmail.com>]

Hi,

Jukka Zitting schrieb:
> Hi,
> 
> On Fri, Aug 29, 2008 at 8:33 PM, Tobias Bocanegra
> <to...@day.com> wrote:
>> how about stalling requests until the update is complete ?

This does probably not really work. Let me explain:

* What do you do if the update fails ? You cannot keep the
   system non-responsive/stalled, right ?
* There is no event saying: I am now stopping the service for
   update. In fact the events are: service unregistered,
   bundle stopping, bundle stopped, bundle updated,
   bundle starting, bundle starting, service registered.

> 
> That would also make startup time when a number of bundles are just
> being loaded much more predictable. Currently you just need to wait a
> while until all bundles are in place, otherwise you get various
> different failures when you try to access your application.

This may be a solution for startup, where you might say: Only be ready
if everything went smoothly. But you do not want to "turn off" the
system just because of a single bundle update, which (taking the service
out of order for a couple of milliseconds) may cause troubles one in a
million of times....

Regards
Felix

Re: Annoyance during update of bundles

[Alexander Klimetschek <ak...@day.com>]

On Mon, Sep 1, 2008 at 7:59 AM, Felix Meschberger <fm...@gmail.com> wrote:
>> On Fri, Aug 29, 2008 at 8:33 PM, Tobias Bocanegra
>> <to...@day.com> wrote:
>>> how about stalling requests until the update is complete ?
>
> This does probably not really work. Let me explain:
>
> * What do you do if the update fails ? You cannot keep the
>   system non-responsive/stalled, right ?
> * There is no event saying: I am now stopping the service for
>   update. In fact the events are: service unregistered,
>   bundle stopping, bundle stopped, bundle updated,
>   bundle starting, bundle starting, service registered.

Hmm, what about sending an custom update event from the web console
(and all other places where Sling code initiates the update, ie.
jcrinstall/jcrbundles)? Only then requests to the servlets in question
would be stalled during the update. If some other code updates bundles
through the OSGi API, the stall feature would not work, but we
wouldn't break the update process.

And regarding failed updates: Is there a way to find out when an
update has failed? Or does it require a timeout until the new bundle
should be in the "started" state?

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com