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 19:19:15 GMT

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

If we aren't talking about replacing it, then even mentioning the
possibility is just hand-waving.

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

That sounds more like a change to how the scoreboard is allocated.

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

inflexible != not rich.  It just doesn't.  The amount of information in
the scoreboard is FAR more than just the actual data.  That makes it a
rich medium.

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

The basic design isn't sound, for the same reason that having the
scoreboard use this format wasn't sound.  It doesn't work.  You end up
having two chunks of memory with the exact same information.  The first
chunk is the scoreboard, and the second is the interpretation of the
scoreboard.  The scoreboard is still fixed, so now instead of just
changing the mod_status code to handle changes to the scoreboard, you have
to change the code that interprets the scoreboard.  You haven't saved any
headaches, you have just added an extra step that is unnecessary.

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

The answer should be that it is up to mod_snmp to gather that information.
Think of it this way.  Let's say that mod_dav does store information about
the DAV lock, what does mod_snmp do with that?  You have to change
mod_snmp to understand what that means.  If you are going to modify
mod_snmp anyway, then just let mod_snmp look at the data directly.  What
happens when mod_snmp wants information you don't keep track of anywhere?
How many bytes were stored on the server using DAV?  Do you keep track of
that right now?  It is up to mod_snmp to find that information and keep
track of it if it wants to.  You can't determine everything that mod_snmp
will want, so don't try, leave that to the guy who writes mod_snmp.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message