httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: [PATCH] mgmt_get_vars hook
Date Wed, 13 Jun 2001 01:12:55 GMT
On Tue, Jun 12, 2001 at 02:03:44PM -0700, Harrie Hazewinkel wrote:
> Ian Holsman wrote:
> 
> > > > mgmt_get_vars("scoreboard.process.request_count.*")
> > > > which would return a hash table with a entry for every
> > > > process/thread
> > 
> > > I beleive this string based approach is a huge overhead. If this

It is not "huge". Just how often are you suggesting this hook be run? And
how fast does it need to be?

We're talking about an administrator querying the status of the server at
various intervals. Or maybe a module/daemon which is logging status once a
minute.

>...
> Thus, there is not way one can define up front how this
> needs to be mapped in a MIB used in an SNMP agent.

MIBs and SNMP are mostly irrelevant to this hook. The hook is about querying
information from different pieces of code within Apache. An SNMP agent can
deal with the mappings.

IMO, our main purpose is to establish a communication mechanism between
mod_status and the various bits that can be displayed in that page. In
particular, a way to detach mod_status from knowing the internals of the
scoreboard.

Anything beyond that is icing on the cake. (and I believe there is plenty)

>...
> Thus, the SNMP portion already needs to have detailed knowledge of
> the management data stored.

The items in the hash table are self-describing: integer, string, or hash
table (of integer, string, or hash ...).

Thus, the module which is dumping out the data knows how to do it.

If you're talking about *semantic* knowledge of what is queried, then that
is a different story. And that knowledge is completely independent of the
(hook-based) mechanics of *retrieving* the data.

>...
> I agree on the concept, but maybe less on the implementation.
> I would rather see something like the ap_mpm_show.
> If a certain variable does not exist it returns some error code
> AP_NOT_IMPLEMENTED.

We cannot use functions. It must be a hook. The use of functions means that
the management module must call a bunch of stuff all over the server. And if
a data-supplying module isn't loaded into the server, then the mgmt module
will fail to load.

Having predefined functions is non-extensible. With a hook, a mgmt module
can "get all data. display all data." Since all the data is self-describing,
this is quite possible.

We can worry about filtering later, as that is an aspect of the module which
*presents* the data. Not necessarily about the hook.

>...
> > > 3) Maybe the module number can provide the highest level and in
> > > each module the module needs to do this themselves.
> > >
> > yep.. but I wouldn't go with a number as there is no way to control
> > the main numbers unless apache has a 'registration' system where people
> > can get assigned a number.
> 
> This is the problem with the approach. But when human readable names
> are used you can have the same conflict some day. There needs to
> be some mechanism to register the numbers or the names.
> This is maybe a task/possibility the ASF should provide.
> (Thinking here like the lines of an IANA as used in the Internet).

We are not a registration service. That is an overhead that we cannot
supply. We have enough to do with just developing, maintaining, and
debugging the code without having to worry about registration processes.

Names are more than fine. People are more than capable of keeping their
names reasonably unique. We can even suggest that people use a name which
includes their domain name (e.g. lyra.foo.bar).

Numbers are a bitch. Ever debug code that uses numbers as the identifier?
Bleck. One of the reasons the HTTP protocol is so prevalent is the ease of
debugging it: it is text. We don't need numbers here; efficiency is not a
concern for this hook (unless you can show otherwise).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message