Jeff Trawick wrote:
On Sat, 26 Feb 2005 22:32:22 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
+1 from me for the general idea. This could be be very helpful for administrators/operators to trace problems of hung requests.
Thanks for taking the time to comment. I think a lot of people would benefit from having more concrete facts in hand (easily) when there are web server issues.
Thanks for providing an interesting patch.
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 the patch, it is switched on and off via ExtendedStatus. And the intention was to require a configure option such as --enable-track-request-phase to even allow the capability. I'll be interested in other opinions on such questions, such as
* should the capability even be in Apache * should the capability be available by default, or made available only by configure-time option
From my personal point of view I would like to see it be available by default.
* should the capability be controlled merely by ExtendedStatus on/off, or by an additional value for ExtendedStatus, or by a independent directive
I think there should be some possibility to configure this separately from the standard ExtendedStatus on/off as some people might not like the additional overhead introduced compared to the current Extended status. I think an additional value to ExtendedStatus could make a configuration less error prone than a separate configuration directive as it should turn on the extended status automatically and thus avoid users who forgot to turn on Extended status asking something like "I turned on e.g. TrackRequestPhase but I do not see anything on the status page"
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.
That could be nice. I'm a little concerned about using the same mechanism for information maintained by core Apache (not as granular but 99.9% reliable) as well as information maintained by arbitrary modules (more granular but not necessarily reliable), particularly if some save-state/restore-state operation is required as the module enters/leaves its own custom phase.
Agreed. Buggy modules could screw this up and thus a different mechanism should be used. Maybe we could just add another unsigned char field like module_phase to worker_score and let modules fill it by a similar parallel mechanism if they like. But the save-state/restore-state problem would remain if the module does not behave "well" and reset the state upon leaving its anounced state. This could lead admins the wrong way if e.g a module does its job but does not reset its state and the next module in the chain does not update the state and hangs.
Modules currently can save whatever state they want on their own and implement a mod_status hook to format it appropriately in their own
I must admit that I did not know this so far.
section of the display, but having a scoreboard field and a column in the output table would make that much easier.
Definitely. I guess the most annoying and complex thing to do with the hook solution above is that the module needs to implement the infomation sharing accross the processes and threads by itself (shared memory, dbm file, whatever). While this is justified if the module wants to save complex information there should be an easier way to simply report the current phase/state of the module.
BTW: What I am currently missing is an easy way to share structures like apr_table / apr_hash / apr_array over processes / threads. Or is there already an easy way and I should spend more time reading the docs instead of complaining :-). But I think this gets off topic and should be discussed on [EMAIL PROTECTED] instead.
Regards
RÃdiger
