httpd-dev mailing list archives

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

> > > Something like ap_get_server_status(char **data, int *data_size);
> > > which calls a server_status hook that modules that care about this
> > > stuff can implement.
> >
> > How is this any different than the scoreboard?  It really sounds to me
> > like we are trying to solve a problem that doesn't exist.  The scoreboard
> > does whbat we need, what is the problem with it?
> The scoreboard is non-extensible. You may also recall that we were working
> on a scoreboard design that was name/value pair oriented. Manoj disappeared
> from httpd development, and the design impetus went with him. We threw out
> all the partial work a while back and reverted to a 1.3 scoreboard design.

We threw it out because it was the wrong design.

> 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.

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

> 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 Bloom               
406 29th St.
San Francisco, CA 94131

View raw message