Re: CGI::Fast / Apache - Strange behaviour?

A program that crashes, especially in a mod_perl or FastCGI environment can cause all kinds of unexpected mayhem and sometimes the effects to "contain" the damage may even be worse or increase the damage. By its very nature a "crash" is uncontrolled and it is anybody's guess what will be its ill effects. It is not always possible to fully clean-up a crash: unreachable memory, zombie processes or runaway processes may remain at large despite our best efforts.

Many years ago (I think it was in one of the Apache 1 versions), there was even an option to bring down the whole server at regular intervals and "reboot" it, just to clean up all accumulated junk and even now there is still a possibility to kill individual Apache worker processes after a certain number of uses.

The windows OS was particularly prone to it, but regularly doing "reboots" during quiet times seemed to avoid the worst effects. The only problem was trying to sell this "solution" to the head of IT as a "feature" rather than a kludge to deal with badly written software.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

My blog: Imperial Deltronics

Comment on Re: CGI::Fast / Apache - Strange behaviour?

Replies are listed 'Best First'.
Re^2: CGI::Fast / Apache - Strange behaviour? by locked_user sundialsvc4 (Abbot) on Aug 17, 2012 at 12:27 UTC
To clarify ... Within my “persistent programs” of any sort, the outer level request handler contains an all-encompassing “exception handler of last resort,” and it carefully examines just what sort of exception has been thrown. That is the reason why I use exception classes, which are objects. (Yes, you can `die` with an object, as well as with a string.) Code that cannot succeed throws an exception of a particular class. (If it invokes code that might not use these classes, it “wraps” that code in an inner exception-handler which throws an exception-class containing among other things the text.) Some exceptions are used as a way to gracefully bail-out from anywhere. Others truly represent detected program flaws. The outer-level handler will catch that fly-ball if nobody else does, and will do something appropriate. It is true that any exception can leave various kinds of “smoking remains” which can accumulate; especially memory. It happens often enough that Plack, for instance, has a so-called “hara kiri” facility which causes the workers to periodically die-off. Sometimes the appropriate response to a certain exception is to die-off immediately. But the outer level handler still has to capture the error traceback (another feature of these exception classes) and to sound the alarm somewhere. Absolutely the worst thing that can happen is an exception that causes incomplete output and that is not correctly trapped or logged as an exception. We have all seen web sites and so-forth that have done this. Usually the output just stops in m `;-)`

Replies are listed 'Best First'.

Re^2: CGI::Fast / Apache - Strange behaviour?
by locked_user sundialsvc4 (Abbot) on Aug 17, 2012 at 12:27 UTC

To clarify ...

Within my “persistent programs” of any sort, the outer level request handler contains an all-encompassing “exception handler of last resort,” and it carefully examines just what sort of exception has been thrown.

That is the reason why I use exception classes, which are objects. (Yes, you can die with an object, as well as with a string.) Code that cannot succeed throws an exception of a particular class. (If it invokes code that might not use these classes, it “wraps” that code in an inner exception-handler which throws an exception-class containing among other things the text.) Some exceptions are used as a way to gracefully bail-out from anywhere. Others truly represent detected program flaws. The outer-level handler will catch that fly-ball if nobody else does, and will do something appropriate.

It is true that any exception can leave various kinds of “smoking remains” which can accumulate; especially memory. It happens often enough that Plack, for instance, has a so-called “hara kiri” facility which causes the workers to periodically die-off. Sometimes the appropriate response to a certain exception is to die-off immediately. But the outer level handler still has to capture the error traceback (another feature of these exception classes) and to sound the alarm somewhere.

Absolutely the worst thing that can happen is an exception that causes incomplete output and that is not correctly trapped or logged as an exception. We have all seen web sites and so-forth that have done this. Usually the output just stops in m

;-)