+1 from me for the general idea. This could be be very helpful for administrators/operators to trace problems of hung requests. As this creates more overhead to the request processing (although I think not too much for me personally) there should be a directive for turning this on/off like ExtendedStatus. In a second step it would be great to see this implemented in a more extensible way such that modules would be able to add their own phases to this list. e.g there could be an API call like ap_add_phase which would add a string to the phase_names array during the configuration phase of a modul and would return the index in the array for later use in the AP_SET_REQUEST_PHASE macro via the module.
Regards
RÃdiger
Jeff Trawick wrote:
Normally, processing of a request proceeds quite normally towards completion. Dependencies on external input however can impact normal processing enough that requests can be hung. (connections to LDAP server timing out? somebody decided to play with the database in the middle of the day and remote application requests are stalled?) Add to that a loop here and there and it gets more exciting. Having a clue about the phase where a request is stalled (looping) can drastically speed up resolution of the problem. Stalling in access checking vs. stalling while waiting for a remote application to generate the response have quite different causes and often have to be diagnosed by two different support teams/vendors (which themselves may be different from the web server support team/vendor).
By tracking the active request phase, it can be displayed by mod_status and can provide a quick guide to where work is piling up, since 'W' doesn't help much when some of the phases covered by 'W' are much more fragile than anything Apache does.
[..deleted more details..]
