Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 58813 invoked by uid 500); 13 Jun 2001 01:06:30 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 58784 invoked from network); 13 Jun 2001 01:06:27 -0000 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Tue, 12 Jun 2001 18:12:55 -0700 From: Greg Stein To: new-httpd@apache.org Subject: Re: [PATCH] mgmt_get_vars hook Message-ID: <20010612181255.S31504@lyra.org> Mail-Followup-To: new-httpd@apache.org References: <3482305AF0F6CF469ED45C0D48FAFCF7091FF4D8@cnet48.cnet.com> <3B2683B0.87A12B6A@covalent.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3B2683B0.87A12B6A@covalent.net>; from harrie@covalent.net on Tue, Jun 12, 2001 at 02:03:44PM -0700 X-URL: http://www.lyra.org/greg/ X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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/