abort_page, AbortScript and ForceAfterScript

[Massimo Manghi <ma...@unipr.it>]

I committed in the branch rivet/branches/neh (new exception handling) the code
that introduces 2 new conf scripts:

 - "AbortScript": the script is invoked after an 'abort_page' commands has
been called and content generation interrupted

 - "ForceAfterScript": the script is run anyway after the page content
generation has ended (also after an 'abort_page')

'abort_page' now accepts an optional arbitrary parameter to be stored
internally in the module globals. The value of this parameter can be retrieved
through the command 'abort_code'.

'abort_page' is effective only on the first call during a request processing:
on all the subsequent calls the command returns TCL_OK and has no effect
whatsoever. This is needed to prevent AbortScript and ForceAfterScript from
returning with a "RIVET" error code that cannot be handled in the same way
it's done during content generation.

Since ForceAfterScript is to be run anyway, the programmer may need to know if
execution happens after page generation was interrupted because of an
'abort_page' call. Hence the command 'abort_page' supports now the form 

abort_page -aborting

that returns 1 if the execution happens after content generation was
interrupted. I know some of you are frowning at this form. Take it a
experimental: I'm open to change it.

It's not too clear to me whether ForceAfterScript should run if ErrorScript
has run....My opinion is that ForceAfterScript could by design be there to
catch resources left in a inconsistent state and it's sensible to run it anyway.

These features are not yet documented. They will be as soon as the code will
meet approval of those who will be bothered testing it.

-- Massimo


---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org

Re: abort_page, AbortScript and ForceAfterScript

[Karl Lehenbauer <ka...@gmail.com>]

On Feb 15, 2011, at 5:18 PM, Massimo Manghi wrote:
> I thought for a while about the possibility of doing recursive handling of the
> abort_page generated error, but I thought in most cases the abort code passed
> to abort_page could help to cope with what required an interruption and there
> wasn't a compelling need for nested interruptions. Maybe I had it wrong, we'll
> see in the practical usage. Furthermore, coding it the way it is required
> little changes

I completely agree with your approach and I don't think it's necessary to try to do anything about recursive abort_page.  It's up to the Rivet developer to make sure their before and after scripts, rivet_error proc, etc, either work properly or reasonably handle when they don't.

Where Rivet callsTcl_Eval* in mod_rivet.c, if an error is returned, it either does special handling in the case of page processing (i.e. Rivet_ExecuteAndCheck) such as handling abort_page, invoking the error script, etc, or it logs the error in every other case.  I think that's prudent and appropriate and really about as much as we should try to do.

Beyond that, it's up to the developer to test and develop reasonable before and after scripts, etc.  FlightAware has a pretty sophisticated ErrorScript proc.  It inserts uncaught tracebacks into a rivet_errors table in the database, along with other stuff like the user ID if logged in, the URL, webserver host, etc.  But of course a lot of things can go wrong with that, like if things are really screwed up we might not even have a database connection.  So we have a dead simple error proc that wraps the fancy one in a catch and does the minimum if that dies.  In fact, here it is:

## NOTE ALSO: If flightaware_error_guts traces back, we exit the child process!
##
proc flightaware_error {} {
    if {[catch flightaware_error_guts catchResult] == 1} {
        catch {::bsd::syslog log error "flightaware_error: TRACEBACK IN flightaware_error!!! - $::errorInfo"}
        catch {puts stderr "TRACEBACK in flightaware_error!" - $::errorInfo - exiting the child!}
        exit 244
    }
}

It might be a little radical to exit the Apache child if rivet_error traces back but our sense (and experience) is that, once it was debugged, a failing flightaware_error_guts meant things were screwed up enough that we didn't want Rivet trying to use the interpreter anymore.

Re: abort_page, AbortScript and ForceAfterScript

[Massimo Manghi <ma...@unipr.it>]

On Tue, 15 Feb 2011 13:43:11 -0600, Karl Lehenbauer wrote
> This looks pretty good.  We'll give it a try.  I was thinking that 
> ForceAfterScript might be called AfterEveryScript.  I just like the 
> sound of it, but no biggie.

I also proposed RequestCatchScript, pointing out the fact this is also the
last chance for settling everything that was left floating in the air, but the
plain descriptive AfterEveryScript is just OK.

> 
> I was also thinking possibly instead of having an AbortScript just 
> have a flag that can be queried to see if the page got here by 
> abort_page or what, but this solves the problem and there's already 
> code written.
> 
> I hadn't thought about the abort-within-an-abort scenario.  I think 
> that's pretty smart.
> 

I thought for a while about the possibility of doing recursive handling of the
abort_page generated error, but I thought in most cases the abort code passed
to abort_page could help to cope with what required an interruption and there
wasn't a compelling need for nested interruptions. Maybe I had it wrong, we'll
see in the practical usage. Furthermore, coding it the way it is required
little changes.

-- Massimo



---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org

Re: abort_page, AbortScript and ForceAfterScript

[Karl Lehenbauer <ka...@gmail.com>]

This looks pretty good.  We'll give it a try.  I was thinking that ForceAfterScript might be called AfterEveryScript.  I just like the sound of it, but no biggie. 

I was also thinking possibly instead of having an AbortScript just have a flag that can be queried to see if the page got here by abort_page or what, but this solves the problem and there's already code written.

I hadn't thought about the abort-within-an-abort scenario.  I think that's pretty smart.

On Feb 11, 2011, at 4:50 PM, Massimo Manghi wrote:

> I committed in the branch rivet/branches/neh (new exception handling) the code
> that introduces 2 new conf scripts:
> 
> - "AbortScript": the script is invoked after an 'abort_page' commands has
> been called and content generation interrupted
> 
> - "ForceAfterScript": the script is run anyway after the page content
> generation has ended (also after an 'abort_page')
> 
> 'abort_page' now accepts an optional arbitrary parameter to be stored
> internally in the module globals. The value of this parameter can be retrieved
> through the command 'abort_code'.
> 
> 'abort_page' is effective only on the first call during a request processing:
> on all the subsequent calls the command returns TCL_OK and has no effect
> whatsoever. This is needed to prevent AbortScript and ForceAfterScript from
> returning with a "RIVET" error code that cannot be handled in the same way
> it's done during content generation.
> 
> Since ForceAfterScript is to be run anyway, the programmer may need to know if
> execution happens after page generation was interrupted because of an
> 'abort_page' call. Hence the command 'abort_page' supports now the form 
> 
> abort_page -aborting
> 
> that returns 1 if the execution happens after content generation was
> interrupted. I know some of you are frowning at this form. Take it a
> experimental: I'm open to change it.
> 
> It's not too clear to me whether ForceAfterScript should run if ErrorScript
> has run....My opinion is that ForceAfterScript could by design be there to
> catch resources left in a inconsistent state and it's sensible to run it anyway.
> 
> These features are not yet documented. They will be as soon as the code will
> meet approval of those who will be bothered testing it.
> 
> -- Massimo
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org