httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <>
Subject RE: Hooks for management reporting (was RE:New Hook)
Date Fri, 08 Jun 2001 16:23:22 GMT

> -----Original Message-----
> From: []
> Sent: Friday, June 08, 2001 8:32 AM
> To:
> Subject: Re: Hooks for management reporting (was RE:New Hook)
> > In another note, you mention shifting this from the 
> scoreboard code to the
> > MPM. I don't see that as true. We can have the scoreboard 
> code implement the
> > hook. If/when we ever desire to: we can migrate the hook 
> response from the
> > scoreboard to MPMs. Or individual MPMs can add their own hook.
> Doesn't really matter if the code lives in the MPM or the scoreboard
> itself.  What is being proposed, is having a scoreboard that 
> keeps track
> of the information, a segment of code that converts the 
> scoreboard to an
> internal table, and a segment of code that converts that table to the
> output for the management module.  Just remove the middle piece.

here's what I am proposing.
that mod_status no longer needs to know the internals of the scoreboard (making replacing
a scoreboard
later on easier)
that the hook outputs a series of name/value pairs. 
These name/value pairs could come from a subset of
either the APM MIB (

or the WWW-MIB

the management module wouldn't need to understand (or have access to) all the internals

This could be done via filters, but I was thinking that there could be multiple management
one in HTML format for users, another in XML for automated responses, and another possibly
all with different output requirements

or are you thinking that the 'scoreboard filter' would dump to name=value pairs, and the management
itself would be a filter sitting on top of it?

I'm in agreement that each module should stored it's own info (outside of the scoreboard)
in shared memory


> If you want to make mod_status extensible, there are two options.
> 1)  Make the scoreboard extensible, literally.  This has been 
> talked about
> for MANY months now.  I started talking about it when I 
> reverted to the
> 1.3 scoreboard, but the shared memory system still isn't in place that
> will allow this to happen.
> 2)  Use filters.  Modules can allocate their own shared 
> memory, and add
> their data to the bottom of the mod_status output.  Other 
> management apps
> do most of their work during the logging phase, and they will by
> definition require modifications to those modules.  Those 
> modifications
> will be one of two things.  In the current model, logging 
> directly to the
> management module's API.  In the proposed hook model, putting 
> the right
> information in the table.
> The problem is simple in my mind.  The management app is the 
> only thing
> that really knows what it wants to display information about. 
>  The module
> can try to figure out what the management app cares about, 
> but 9 times out
> of 10, it will be wrong.  So, either every module will log too much
> information, or it won't log enough.  If you leave it to the 
> management
> app to figure out what to log and when to log it, you resolve this
> problem.
> > I do see that this can be useful. Consider the SSL 
> certificate cache. How do
> > we get status on that thing? One of these days, I'd like to 
> keep the DAV
> > lock database open (rather than re-open per request) and 
> having status on
> > this global state would be nice, too.
> Both of those are solved by having each module create it's own shared
> memory segment and store the information in there.  To display that
> information, that's a perfect example of why filters are so cool.
> Ryan
> ______________________________________________________________
> _________________
> Ryan Bloom               
> 406 29th St.
> San Francisco, CA 94131
> --------------------------------------------------------------
> -----------------

View raw message