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 18:28:02 GMT
On Fri, Jun 08, 2001 at 10:42:31AM -0700, wrote:
> > 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.
> Why are we talking about replacing the scoreboard?

He is NOT talking about replacing it. He is saying that we *could* replace
it more easily, if we unwire mod_status from the particular scoreboard

I could easily see a different scoreboard format for purely-threaded MPMs.
We wouldn't need any "hard limit" on the thread count; we just associate
data directly with the thread, and the hook function gathers it up.

> Again, you are
> talking about taking a rich communication medium (the scoreboard),

The scoreboard is not "rich". It is a very fixed, very hard-wired chunk of
shared memory. It is quite inflexible.

> and
> translating it into a poot medium (this name/value pairs).  The scoreboard
> has all sorts of information that is stored in the make-up of the
> scoreboard.  For example, anything that is an int in the scoreboard
> actually conveys more information than just the actual number.  Going to
> key/value pairs, means that we lose that intrinsic information.

Ian's current key/value pair could use a bit more work to allow for more
structured data. But the basic design is sound. It uncouples two chunks of
code, thus freeing them to make more decisions on their own.

> No.  The scoreboard is just a shared table.  Mod_status uses the
> scoreboard to output information about the server.  Any other filters that
> are invoked would be responsible for adding their out status information
> to the status page.  The fact is that most management modules won't be
> using the handler or filter phase.  For example, mod_snmp can completely
> ignore those phases.  That module just gathers information, and outputs it
> to the SNMP agent in the logging phase.  There is no need for a filter for
> mod_snmp.

The question is how mod_snmp gathers data from places *other* than the
scoreboard. That is what his hook is for. We cannot and should not hard-wire
a bazillion query functions across the server. If we use a hook, then
mod_snmp can gather data.


Greg Stein,

View raw message