httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Hooks for management reporting (was RE:New Hook)
Date Fri, 08 Jun 2001 07:05:47 GMT
On Thu, Jun 07, 2001 at 08:44:27PM -0700, wrote:
> On Thu, 7 Jun 2001, Greg Marr wrote:
> > At 02:50 PM 06/07/2001, Greg Stein wrote:
> > >On Thu, Jun 07, 2001 at 09:43:24AM -0700, Ian Holsman wrote:
> > >>I was wondering if it would be usefull if there was some kind of
> > >>'status' hook which modules could implement to tell management apps
> > >>(mod_snmp/mod_status) what is going on inside of them.
> > >>
> > >>it would return an array name/value pairs, which the management
> > >>module could convert into a fancy table layout on the status page,
> > >>or a group of SNMP OID's this would allow a module designer not to
> > >>mess with mod_status, and maybe a way of getting the scoreboard
> > >>code out of mod_status
> > >
> > >The current design is for mod_status to *pull* the information when
> > >it is needed. Considering that pulling is *much* less frequent than
> > >status changes, this is much more efficient for the system.  (a
> > >status hook is a *push*)n
> >
> > It could be implemented as something that mod_status calls when it
> > needs the status.  If it's done in the core, then any management app
> > could use it.

Ah! I saw the hook as a "push status" rather than what the external code
uses to pull it from whatever pieces maintain status.

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

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.

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.

I could also see this hook as being for *config info* rather than just
runtime state. Currently, mod_info reaches into structures that it probably
shouldn't know anything about. The hook would isolate the two pieces. In
this future scenario, the core would expose the config tree bits via the
info/state hook.


Greg Stein,

View raw message