Annoyance during update of bundles

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

Hi all,

when I update a bundle containing a servlet (eg. servlet path =
/bin/myservlet) and I hit my curl command for testing that servlet
(POST to /bin/myservlet + a few specific params) too fast, ie. in the
time when the old version of the bundle is gone, but the new version
is not yet started, and hence nothing is registered under
/bin/myservlet, the request is handled by the SlingPostServlet, which
in this case creates a new JCR node under /bin/myservlet.

Any ideas how to circumvent this little annoyance during development?

Regards,
Alex

PS: I would like to have a nice "ding" sound once the bundle update
completed successfully ;-)

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Annoyance during update of bundles

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Sep 2, 2008 at 10:15 AM, Felix Meschberger <fm...@gmail.com> wrote:

> ...What you are looking for are messages of the form "BUNDLE STARTED"
> (which comes after "BUNDLE UPDATED") or "FrameworkEvent PACKAGES
> REFRESHED", which comes at the end of the installation/update....

If we include a possibility for resetting the "sling ready" flag in
SLING-490, we could use these events to reset this flag.

Resetting it on any bundle stopped/updated event would help in
Alexander's case, assuming the appropriate "readyness scripts" are
used. That would be a good motivation to setup those scripts, which
then helps in production environments as well.

-Bertrand

Re: Annoyance during update of bundles

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

Hi,

Alexander Klimetschek schrieb:
> On Mon, Sep 1, 2008 at 11:31 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> I'm wondering what we really want to achieve here and if it is worth the
>> effort?
>> For production systems this is imho more a non-issue, as you usually
>> don't update directly a productive machine.
>>
>> For development you know that you updated a bundle and shouldn't send
>> new requests during the update. Now, the problem is perhaps, that in
>> some cases the update itself takes longer. This could be because of
>> inefficient bundling, too many references etc.
> 
> Yes, as I've written in my PS, another solution would be a good
> indicator of when the bundle update is done. In my case I use the
> sling:install maven plugin goal, which does not wait for the bundle
> update to be finished. So I can either look at the sling log and try
> to separate normal messages from bundle install/start entries or look
> at the cpu usage of my computer and wait for it to drop again. Both
> are rather "fuzzy" ;-)

What you are looking for are messages of the form "BUNDLE STARTED"
(which comes after "BUNDLE UPDATED") or "FrameworkEvent PACKAGES
REFRESHED", which comes at the end of the installation/update.

> 
> No, what about letting the sling-install http request wait until the
> update is finished? Or an improved felix web console that shows
> current installs separately and updates in real-time (via ajax)?

The maven sling plugin uses the same functionality as the web console to
install or update a bundle. And the web console performs the actual
installation or update in the background - mainly to prevent the console
from blocking.

Now, theoretically, the asynchronous update would only be required for
the web console bundle itself, but it turned out that it is better to
generally run these operations asynchronously.

So, I am constantly thinking of a way to provide feedback from the
asynchronous thread to the console (or the plugin) about the outcome and
state of the update (termination with success or failure). I have not
found a solution yet ...

Regards
Felix

Re: Annoyance during update of bundles

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

On Mon, Sep 1, 2008 at 11:31 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> I'm wondering what we really want to achieve here and if it is worth the
> effort?
> For production systems this is imho more a non-issue, as you usually
> don't update directly a productive machine.
>
> For development you know that you updated a bundle and shouldn't send
> new requests during the update. Now, the problem is perhaps, that in
> some cases the update itself takes longer. This could be because of
> inefficient bundling, too many references etc.

Yes, as I've written in my PS, another solution would be a good
indicator of when the bundle update is done. In my case I use the
sling:install maven plugin goal, which does not wait for the bundle
update to be finished. So I can either look at the sling log and try
to separate normal messages from bundle install/start entries or look
at the cpu usage of my computer and wait for it to drop again. Both
are rather "fuzzy" ;-)

No, what about letting the sling-install http request wait until the
update is finished? Or an improved felix web console that shows
current installs separately and updates in real-time (via ajax)?

Regards,
Alex


-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Annoyance during update of bundles

[Carsten Ziegeler <cz...@apache.org>]

I'm wondering what we really want to achieve here and if it is worth the
effort?
For production systems this is imho more a non-issue, as you usually
don't update directly a productive machine.

For development you know that you updated a bundle and shouldn't send
new requests during the update. Now, the problem is perhaps, that in
some cases the update itself takes longer. This could be because of
inefficient bundling, too many references etc.

Just my 2cents :)

Carsten

Alexander Klimetschek wrote:
> On Mon, Sep 1, 2008 at 11:02 AM, Felix Meschberger <fm...@gmail.com> wrote:
>> This is of course also a possible scenario in a live environment, esp.
>> in environments used globally: Imagine an IT department in USA updating
>> the bundle while a user in Germany tries to use the service ...
>>
>> How about this approach: Based on the knowledge, that the
>> SlingPostServlet is the default servlet for POST requests, we might :
>>
>> * Define a special operation in the SlingPostServlet, say "nop" (those
>> of us remembering the old 6502 CPU might remember that ;-).
>> * To be able to convey some expected "failure" status, we might add a
>> parameter to this operation, say :nopstatus which conveys the status
>> code to send back.
>> * The :operation and :nopstatus (or generally all ":" prefixed
>> parameters) are ignored by your POST servlet
>>
>> Now the client side of your POST servlet adds the following parameters:
>>    :operation=nop
>>    :nopstatus=503
>>
>> If your POST servlet is active, the :operation and :nopstatus parameters
>> are just ignored and everything runs smoothly. If your POST servlet is
>> inactive, the SlingPostServlet is triggered, which sends back the 503
>> status as a result of executing the "nop" operation.
>>
>> This mechanism can even be used to verify the SlingPostServlet is active
>> (provided no other POST servlet interferes ;-) ).
> 
> Well, this is a solution, but this requires specifics of the
> SlingPostServlet (the no-operation parameter) to be represented in my
> client-side code, which I don't like. And it is not a generic solution
> that solves the other issues mentioned in the thread (eg. jsp compile
> issues) - or if some other default servlet gets triggered, depending
> on the resource type and the servlet resolution.
> 
> Regards,
> Alex
> 


-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Annoyance during update of bundles

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

On Mon, Sep 1, 2008 at 11:02 AM, Felix Meschberger <fm...@gmail.com> wrote:
> This is of course also a possible scenario in a live environment, esp.
> in environments used globally: Imagine an IT department in USA updating
> the bundle while a user in Germany tries to use the service ...
>
> How about this approach: Based on the knowledge, that the
> SlingPostServlet is the default servlet for POST requests, we might :
>
> * Define a special operation in the SlingPostServlet, say "nop" (those
> of us remembering the old 6502 CPU might remember that ;-).
> * To be able to convey some expected "failure" status, we might add a
> parameter to this operation, say :nopstatus which conveys the status
> code to send back.
> * The :operation and :nopstatus (or generally all ":" prefixed
> parameters) are ignored by your POST servlet
>
> Now the client side of your POST servlet adds the following parameters:
>    :operation=nop
>    :nopstatus=503
>
> If your POST servlet is active, the :operation and :nopstatus parameters
> are just ignored and everything runs smoothly. If your POST servlet is
> inactive, the SlingPostServlet is triggered, which sends back the 503
> status as a result of executing the "nop" operation.
>
> This mechanism can even be used to verify the SlingPostServlet is active
> (provided no other POST servlet interferes ;-) ).

Well, this is a solution, but this requires specifics of the
SlingPostServlet (the no-operation parameter) to be represented in my
client-side code, which I don't like. And it is not a generic solution
that solves the other issues mentioned in the thread (eg. jsp compile
issues) - or if some other default servlet gets triggered, depending
on the resource type and the servlet resolution.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Annoyance during update of bundles

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

Hi,

Alexander Klimetschek schrieb:
> Hi all,
> 
> when I update a bundle containing a servlet (eg. servlet path =
> /bin/myservlet) and I hit my curl command for testing that servlet
> (POST to /bin/myservlet + a few specific params) too fast, ie. in the
> time when the old version of the bundle is gone, but the new version
> is not yet started, and hence nothing is registered under
> /bin/myservlet, the request is handled by the SlingPostServlet, which
> in this case creates a new JCR node under /bin/myservlet.
> 
> Any ideas how to circumvent this little annoyance during development?

This is of course also a possible scenario in a live environment, esp.
in environments used globally: Imagine an IT department in USA updating
the bundle while a user in Germany tries to use the service ...

How about this approach: Based on the knowledge, that the
SlingPostServlet is the default servlet for POST requests, we might :

* Define a special operation in the SlingPostServlet, say "nop" (those
of us remembering the old 6502 CPU might remember that ;-).
* To be able to convey some expected "failure" status, we might add a
parameter to this operation, say :nopstatus which conveys the status
code to send back.
* The :operation and :nopstatus (or generally all ":" prefixed
parameters) are ignored by your POST servlet

Now the client side of your POST servlet adds the following parameters:
    :operation=nop
    :nopstatus=503

If your POST servlet is active, the :operation and :nopstatus parameters
are just ignored and everything runs smoothly. If your POST servlet is
inactive, the SlingPostServlet is triggered, which sends back the 503
status as a result of executing the "nop" operation.

This mechanism can even be used to verify the SlingPostServlet is active
(provided no other POST servlet interferes ;-) ).

WDYT ?

Regards
Felix

Re: Annoyance during update of bundles

[Alexander Saar <al...@googlemail.com>]

Am 29.08.2008 um 16:50 schrieb Alexander Klimetschek:

> Hi all,
>
> when I update a bundle containing a servlet (eg. servlet path =
> /bin/myservlet) and I hit my curl command for testing that servlet
> (POST to /bin/myservlet + a few specific params) too fast, ie. in the
> time when the old version of the bundle is gone, but the new version
> is not yet started, and hence nothing is registered under
> /bin/myservlet, the request is handled by the SlingPostServlet, which
> in this case creates a new JCR node under /bin/myservlet.
>
> Any ideas how to circumvent this little annoyance during development?
if you don't need it for your development and testing you can just  
disable the SlingPostServlet service in the Felix console

regards alex

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

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

[Jukka Zitting <ju...@gmail.com>]

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 ?

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.

BR,

Jukka Zitting

Re: Annoyance during update of bundles

[Tobias Bocanegra <to...@day.com>]

On 8/30/08, Alexander Klimetschek <ak...@day.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 ?
>
>
> Good idea. This would also save one from all the other problems you
>  can get (html node render servlet triggered, jsp compile errors,
>  etc.).
>
>  But I am not sure if this is what you want in a production system - if
>  you have high traffic and most requests don't use the servlets or
>  services provided by the bundle that is updated. Maybe it's possible
>  to stall only requests to the servlets that are provided by the bundle
>  in question.
well. rather having no requests than broken ones. after all, a bundle
update should not take longer than a couple of seconds...so i think
this is acceptable.

regards, toby

Re: Annoyance during update of bundles

[Bertrand Delacretaz <bd...@apache.org>]

On Sat, Aug 30, 2008 at 11:15 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> We have discussed a related feature:
>
> https://issues.apache.org/jira/browse/SLING-490...

The plan in that issue was to compute the "Sling ready" flag once and
have it set forever, but it might be useful to allow the flag to be
reset to handle cases such as Alex's.

I have added a note to SLING-490 about that.

-Bertrand

> ...Alexander Klimetschek wrote:
>> ...Maybe it's possible
>> to stall only requests to the servlets that are provided by the bundle
>> in question....

Re: Annoyance during update of bundles

[Carsten Ziegeler <cz...@apache.org>]

We have discussed a related feature:

https://issues.apache.org/jira/browse/SLING-490

Volunteers? :)

Carsten

Alexander Klimetschek 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 ?
> 
> Good idea. This would also save one from all the other problems you
> can get (html node render servlet triggered, jsp compile errors,
> etc.).
> 
> But I am not sure if this is what you want in a production system - if
> you have high traffic and most requests don't use the servlets or
> services provided by the bundle that is updated. Maybe it's possible
> to stall only requests to the servlets that are provided by the bundle
> in question.
> 
> Regards,
> Alex
> 


-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Annoyance during update of bundles

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

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

Good idea. This would also save one from all the other problems you
can get (html node render servlet triggered, jsp compile errors,
etc.).

But I am not sure if this is what you want in a production system - if
you have high traffic and most requests don't use the servlets or
services provided by the bundle that is updated. Maybe it's possible
to stall only requests to the servlets that are provided by the bundle
in question.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Annoyance during update of bundles

[Tobias Bocanegra <to...@day.com>]

how about stalling requests until the update is complete ?
regards, toby

On 8/29/08, Alexander Klimetschek <ak...@day.com> wrote:
> Hi all,
>
>  when I update a bundle containing a servlet (eg. servlet path =
>  /bin/myservlet) and I hit my curl command for testing that servlet
>  (POST to /bin/myservlet + a few specific params) too fast, ie. in the
>  time when the old version of the bundle is gone, but the new version
>  is not yet started, and hence nothing is registered under
>  /bin/myservlet, the request is handled by the SlingPostServlet, which
>  in this case creates a new JCR node under /bin/myservlet.
>
>  Any ideas how to circumvent this little annoyance during development?
>
>  Regards,
>  Alex
>
>  PS: I would like to have a nice "ding" sound once the bundle update
>  completed successfully ;-)
>
>
>  --
>  Alexander Klimetschek
>  alexander.klimetschek@day.com
>