On 6/18/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
On 06/18/2006 04:03 PM, Jeff Trawick wrote:
>> > On 06/17/2006 08:57 AM, Alexander Lazic wrote:
>> > > On Sam 17.06.2006 00:54, Ruediger Pluem wrote:
>> > >> From my current point of view the answer is: No, this is not
>> possible
>> > >> out of the box.
>> > >> It may be possible if you modify the hook macros.
>
>
> yep
>
> Getting inside these macros is what enables diagnostic features such as
>
> a) mod_status display of where a request is being held up
But this feature is not in our codebase, right? Is it a patch to the macros
+ an additional module that hooks itself into the status_hook? Just curious.
not in our code base
what I do is replace stuff like
ap_run_handler (a macro)
with
foo_run_handler (a function)
which will check ap_extended_status; if off, it will just "return
ap_run_handler";
otherwise, it essentially has the macro expansion, but it has the
following logic around the module call:
worker_score->module_index = handler_modindexes[n];
rv = pHook[n].dummy(r);
if (rv != DECLINED) {
worker_score->module_index = 0;
apr_table_set(r->subprocess_env,
REQUEST_ENVVAR,
apr_psprintf(r->pool,
"(%s/%d/handler)",
modnames[handler_modindexes[n]],
rv);
return rv;
}
If we reach the end without a module handling it:
worker_score->module_index = 0;
return DECLINED;
At initialization, the handler_modindexes function is built to
correspond to the hook_array.
Meanwhile, mod_status and a few other diagnostic modules know how to
turn a module index into a module name.
I put this problem determination aid in four hook calls which have
proven interesting w.r.t. third-party modules: handler, access
checker, check user id, log transaction. I didn't care about any
performance difference between a hook macro in mainline vs. call to a
function which checks ap_extended_status and then invokes the macro.
I did check the CPU usage difference between ExtendedStatus on and
ExtendedStatus off after adding this logic. It is still in the
neighborhood of a 1-2% increase, which is well worth it.
--/--
[EMAIL PROTECTED] or [EMAIL PROTECTED]
Implementation wise, what we are using is not a simple function call
or two which could be cleanly inserted into the apr-util hook macro
expansion. The problem determination aid is dependent on
* the data structures behind the hook macros
* the Apache module index, which needs to be stored in those data
structures or in a parallel data structure so that it can be accessed
efficiently while walking through the hook array
* the worker_score
If httpd *developers* are interested, we should decide what type of
processing is acceptable/required first and worry about whether it can
be fitted into apr second. As I recall from the last discussion of
this perhaps 15 months ago, most all of the interest was from web
admin lurkers, and there was insufficient developer interest anyway.
