You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Harrie Hazewinkel <ha...@covalent.net> on 2001/04/11 17:54:37 UTC
[PATCH] mpm_query
HI,
Attached is a patch that enables the mpm_query function
to return more information. It returns for instance,
the HARD_SERVER_LIMIT and HARD_THREAD_LIMIT.
Note: I only was able to test it in the preforked
MPM, due to my system I guess.
Harrie
--
phone: +39-3474932300
http://www.lisanza.net/
Re: [PATCH] mpm_query
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
From: <rb...@covalent.net>
Sent: Wednesday, April 11, 2001 11:37 AM
> On Wed, 11 Apr 2001, Harrie Hazewinkel wrote:
>
> > HI,
> >
> > Attached is a patch that enables the mpm_query function
> > to return more information. It returns for instance,
> > the HARD_SERVER_LIMIT and HARD_THREAD_LIMIT.
> >
> > Note: I only was able to test it in the preforked
> > MPM, due to my system I guess.
> > apr_procattr_t *attr,
> > apr_pool_t *p);
> >
> > + /* The MPM types below should actually a string which enables better identification */
> > + #define AP_MPMQ_BEOS 1 /* MPM:Beos */
> > + #define AP_MPMQ_PERCHILD 2 /* MPM:perchild */
> > + #define AP_MPMQ_PREFORK 3 /* MPM:prefork */
> > + #define AP_MPMQ_SPMT_OS2 4 /* MPM:spmt_os2 */
> > + #define AP_MPMQ_WINNT 5 /* MPM:winnt */
> > + #define AP_MPMQ_THREADED 6 /* MPM:threaded */
>
> I dislike this. The Modules shouldn't care which MPM they are running on.
> Why do we need this option? Other than that, the patch looks good. Could
> oyu please generate unified patches from now on, they are much easier to
> debug.
Let us assume for a moment that it's completely proper.
Since 3rd parties will possibly introduce mpm's, can we do this with a string
instead of a number pool we must mangle^H^H^H^H^H^Hmanage?
Bill
Re: [PATCH] mpm_query
Posted by rb...@covalent.net.
> > + /* The MPM types below should actually a string which enables better identification */
> > + #define AP_MPMQ_BEOS 1 /* MPM:Beos */
> > + #define AP_MPMQ_PERCHILD 2 /* MPM:perchild */
> > + #define AP_MPMQ_PREFORK 3 /* MPM:prefork */
> > + #define AP_MPMQ_SPMT_OS2 4 /* MPM:spmt_os2 */
> > + #define AP_MPMQ_WINNT 5 /* MPM:winnt */
> > + #define AP_MPMQ_THREADED 6 /* MPM:threaded */
>
> I dislike this. The Modules shouldn't care which MPM they are running on.
> Why do we need this option? Other than that, the patch looks good. Could
> oyu please generate unified patches from now on, they are much easier to
> debug.
s/debug/review
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] mpm_query
Posted by rb...@covalent.net.
On Wed, 11 Apr 2001, Harrie Hazewinkel wrote:
> rbb@covalent.net wrote:
> >
> > On Wed, 11 Apr 2001, Harrie Hazewinkel wrote:
> >
> > > rbb@covalent.net wrote:
> > > [snip]
> > > >
> > > > Why is this useful? Isn't it more useful to know whether it is threaded
> > > > or process based. Between that information and the OS, is that enough? I
> > > > would rather add information like THREADS_DYNAMIC or THREADS_STATIC and
> > > > PROCESSES_DYNAMIC or PROCESSES_STATIC, to basically say if the number of
> > > > threads/process is static or not, and if the number of processes is
> > > > static.
> > > >
> > > > I want to decouple the MPM query function from an actual name. The goal
> > > > should be to report the properties of the MPM, not which exact MPM was
> > > > used. Once that is done, the need for the string disappears.
> > >
> > > That means, you cannot determine the MPM used. The values
> > > IS_THREADED and IS_FORKED are not uniquely identifying.
> > > The MPM type determines how the threads and processes are
> > > handled. For instance, perchild and threaded are both
> > > IS_THREADED == 1 and IS_FORKED == 1.
> >
> > That's true, but take a look at what I suggested please. I suggested
> > adding two more queries. THREADS_STATIC and PROCESSES_STATIC
>
> Yes, I noted that, but tomorrow some other MPM
> with similar features comes up. Providing the
> MPM via its name even if that could clash, but
> will most likely clash less.
>
> For instance,
> company foo would call there derived threaded MPM foo_threaded and
> company bar would call there derived threaded MPM bar_threaded.
> And they have similar features to threaded.
But you can't use those names for anything, because company foo might call
it foo_mpm, and your module doesn't have any idea what a foo_mpm looks
like. So, the name is completely useless for anything other than just
reporting the name to a user.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] mpm_query
Posted by Harrie Hazewinkel <ha...@covalent.net>.
rbb@covalent.net wrote:
>
> On Wed, 11 Apr 2001, Harrie Hazewinkel wrote:
>
> > rbb@covalent.net wrote:
> > [snip]
> > >
> > > Why is this useful? Isn't it more useful to know whether it is threaded
> > > or process based. Between that information and the OS, is that enough? I
> > > would rather add information like THREADS_DYNAMIC or THREADS_STATIC and
> > > PROCESSES_DYNAMIC or PROCESSES_STATIC, to basically say if the number of
> > > threads/process is static or not, and if the number of processes is
> > > static.
> > >
> > > I want to decouple the MPM query function from an actual name. The goal
> > > should be to report the properties of the MPM, not which exact MPM was
> > > used. Once that is done, the need for the string disappears.
> >
> > That means, you cannot determine the MPM used. The values
> > IS_THREADED and IS_FORKED are not uniquely identifying.
> > The MPM type determines how the threads and processes are
> > handled. For instance, perchild and threaded are both
> > IS_THREADED == 1 and IS_FORKED == 1.
>
> That's true, but take a look at what I suggested please. I suggested
> adding two more queries. THREADS_STATIC and PROCESSES_STATIC
Yes, I noted that, but tomorrow some other MPM
with similar features comes up. Providing the
MPM via its name even if that could clash, but
will most likely clash less.
For instance,
company foo would call there derived threaded MPM foo_threaded and
company bar would call there derived threaded MPM bar_threaded.
And they have similar features to threaded.
> Now, we get the following results:
>
> threaded
> IS_THREADED 1
> IS_FORKED 1
> THREADS_STATIC 1
> PROCESSES_STATIC 0
>
> perchild
> IS_THREADED 1
> IS_FORKED 1
> THREADS_STATIC 0
> PROCESSES_STATIC 1
>
> My goal is to not rely on the name at all. We have already changed the
> name of the threaded MPM once, and there have been peple talking about
> changing the name of the OS/2 and Windows MPMs. We don't want to rely on
> the names for anything outside of the MPM if we can avoid it at all.
>
> This function should be querying operational properties of the MPM, not
> specific details of the MPM.
>
> Ryan
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
--
phone: +39-3474932300
http://www.lisanza.net/
Re: [PATCH] mpm_query
Posted by rb...@covalent.net.
On Wed, 11 Apr 2001, Harrie Hazewinkel wrote:
> rbb@covalent.net wrote:
> [snip]
> >
> > Why is this useful? Isn't it more useful to know whether it is threaded
> > or process based. Between that information and the OS, is that enough? I
> > would rather add information like THREADS_DYNAMIC or THREADS_STATIC and
> > PROCESSES_DYNAMIC or PROCESSES_STATIC, to basically say if the number of
> > threads/process is static or not, and if the number of processes is
> > static.
> >
> > I want to decouple the MPM query function from an actual name. The goal
> > should be to report the properties of the MPM, not which exact MPM was
> > used. Once that is done, the need for the string disappears.
>
> That means, you cannot determine the MPM used. The values
> IS_THREADED and IS_FORKED are not uniquely identifying.
> The MPM type determines how the threads and processes are
> handled. For instance, perchild and threaded are both
> IS_THREADED == 1 and IS_FORKED == 1.
That's true, but take a look at what I suggested please. I suggested
adding two more queries. THREADS_STATIC and PROCESSES_STATIC
Now, we get the following results:
threaded
IS_THREADED 1
IS_FORKED 1
THREADS_STATIC 1
PROCESSES_STATIC 0
perchild
IS_THREADED 1
IS_FORKED 1
THREADS_STATIC 0
PROCESSES_STATIC 1
My goal is to not rely on the name at all. We have already changed the
name of the threaded MPM once, and there have been peple talking about
changing the name of the OS/2 and Windows MPMs. We don't want to rely on
the names for anything outside of the MPM if we can avoid it at all.
This function should be querying operational properties of the MPM, not
specific details of the MPM.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] mpm_query
Posted by Harrie Hazewinkel <ha...@covalent.net>.
rbb@covalent.net wrote:
[snip]
>
> Why is this useful? Isn't it more useful to know whether it is threaded
> or process based. Between that information and the OS, is that enough? I
> would rather add information like THREADS_DYNAMIC or THREADS_STATIC and
> PROCESSES_DYNAMIC or PROCESSES_STATIC, to basically say if the number of
> threads/process is static or not, and if the number of processes is
> static.
>
> I want to decouple the MPM query function from an actual name. The goal
> should be to report the properties of the MPM, not which exact MPM was
> used. Once that is done, the need for the string disappears.
That means, you cannot determine the MPM used. The values
IS_THREADED and IS_FORKED are not uniquely identifying.
The MPM type determines how the threads and processes are
handled. For instance, perchild and threaded are both
IS_THREADED == 1 and IS_FORKED == 1.
Harrie
--
phone: +39-3474932300
http://www.lisanza.net/
Re: [PATCH] mpm_query
Posted by David Reid <dr...@jetnet.co.uk>.
> > > I would prefer to not modify the API
> > > unless we need to now.
>
Agreed. In fact haven't we been doing that for a good while now?
> >
> > Who determines the need?? I see a use and need for it. Does that count??
> > Or since I am not an hard-core Apache developper or ASF-member, it does
> > not count??
>
???? Duh?
>
> The need is determined by consensus on this list. If you can convince the
> people on this list that there is a need, then the change will be made.
> Those are the same rules that we all live by. I can't just make a change
> to the code. If anybody on this list has a problem with the change, they
> can question that change, and I have to back it up.
>
As has been done a few times :)
>
> > > Not that I am dead-set against changing the API, I
> > > just want a good reason before we do so. I don't believe that allowing
> > > modules to query the name of the MPM is a good reason. IMHO, the correct
> > > way for somebody to get the name of the MPM, is to use the ServerString.
> >
> > The server string gives way more information that needed here.
>
Why is that a problem? Let the client get the parts they want? Never known
providing too much information to be a problem...
> >
> > The problem is that since we do not standardise the capabilities
> > the 2 capabilites Ryan would add are not enough. In operational
> > environments it is mostly very usefull to know its name or
> > vendor of some piece of software, since it may have behavior
> > (for instance seg-faults) under certain conditions. This is indeed
> > the gray area, but for operators this is part of experience.
> > More like, ah, that machine we see this, which version does it have??
> > Ok, that happens more, we fix it this way.
>
Server string seems like it does this already, and if it doesn't it's a simple
change. Don't really see the point of this, sorry.
>
> Fine, yes it might be useful to get the MPM name. If that is the case,
> then use a separate function to get the name. Do not overload the
> MPM_query function.
+1 KISS
david
Re: [PATCH] mpm_query
Posted by rb...@covalent.net.
On Thu, 12 Apr 2001, Harrie Hazewinkel wrote:
> rbb@covalent.net wrote:
> [snip]
> > >
> > > Beyond that, there is nothing wrong with being informative :-)
>
> I could not say it better.
>
> >
> > My problem with the name, is that it requires chaning the API or adding a
> > new API to deal with a string.
>
> Maybe this is some argument, but completely invalid. I interpret this
> as I am lazy and don't want to do it. And how do you handle different
> MPMs that have the same capabilities. Most likely with some name
> provided by the MPM module you know more.
This isn't being lazy. This is trying to hold down API creep. I have no
problem changing APIs or adding new ones. I break backwards compatability
almost daily. I do have a problem adding APIs that I haven't heard a
compelling use for. The only use that makes any sense at all for this
string, is for reporting uses. I would suggest that if you absolutely
want to be able to report the MPM name, then use a different function.
> > I would prefer to not modify the API
> > unless we need to now.
>
> Who determines the need?? I see a use and need for it. Does that count??
> Or since I am not an hard-core Apache developper or ASF-member, it does
> not count??
The need is determined by consensus on this list. If you can convince the
people on this list that there is a need, then the change will be made.
Those are the same rules that we all live by. I can't just make a change
to the code. If anybody on this list has a problem with the change, they
can question that change, and I have to back it up.
> > Not that I am dead-set against changing the API, I
> > just want a good reason before we do so. I don't believe that allowing
> > modules to query the name of the MPM is a good reason. IMHO, the correct
> > way for somebody to get the name of the MPM, is to use the ServerString.
>
> The server string gives way more information that needed here.
>
> The problem is that since we do not standardise the capabilities
> the 2 capabilites Ryan would add are not enough. In operational
> environments it is mostly very usefull to know its name or
> vendor of some piece of software, since it may have behavior
> (for instance seg-faults) under certain conditions. This is indeed
> the gray area, but for operators this is part of experience.
> More like, ah, that machine we see this, which version does it have??
> Ok, that happens more, we fix it this way.
Fine, yes it might be useful to get the MPM name. If that is the case,
then use a separate function to get the name. Do not overload the
MPM_query function.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] mpm_query
Posted by Harrie Hazewinkel <ha...@covalent.net>.
rbb@covalent.net wrote:
[snip]
> >
> > Beyond that, there is nothing wrong with being informative :-)
I could not say it better.
>
> My problem with the name, is that it requires chaning the API or adding a
> new API to deal with a string.
Maybe this is some argument, but completely invalid. I interpret this
as I am lazy and don't want to do it. And how do you handle different
MPMs that have the same capabilities. Most likely with some name
provided by the MPM module you know more.
> I would prefer to not modify the API
> unless we need to now.
Who determines the need?? I see a use and need for it. Does that count??
Or since I am not an hard-core Apache developper or ASF-member, it does
not
count??
> Not that I am dead-set against changing the API, I
> just want a good reason before we do so. I don't believe that allowing
> modules to query the name of the MPM is a good reason. IMHO, the correct
> way for somebody to get the name of the MPM, is to use the ServerString.
The server string gives way more information that needed here.
The problem is that since we do not standardise the capabilities
the 2 capabilites Ryan would add are not enough. In operational
environments it is mostly very usefull to know its name or
vendor of some piece of software, since it may have behavior
(for instance seg-faults) under certain conditions. This is indeed
the gray area, but for operators this is part of experience.
More like, ah, that machine we see this, which version does it have??
Ok, that happens more, we fix it this way.
Harrie
--
phone: +39-3474932300
http://www.lisanza.net/
Re: [PATCH] mpm_query
Posted by rb...@covalent.net.
On Wed, 11 Apr 2001, William A. Rowe, Jr. wrote:
> From: <rb...@covalent.net>
> Sent: Wednesday, April 11, 2001 12:39 PM
>
>
> > On Wed, 11 Apr 2001, Sander van Zoest wrote:
> >
> > > The more accurate information you have in the noc the better. Why monitor
> > > if you do not know what you are monitoring?
> >
> > The problem is that the MPM name is not accurate. We have a habit of
> > changing names of things. The MPM properties are the best way to
> > determine the behavior of the MPM IMNSHO.
>
> 100% correct that we need to test features (dynamically), not the arbitrary
> name of some MPM.
>
> Beyond that, there is nothing wrong with being informative :-)
My problem with the name, is that it requires chaning the API or adding a
new API to deal with a string. I would prefer to not modify the API
unless we need to now. Not that I am dead-set against changing the API, I
just want a good reason before we do so. I don't believe that allowing
modules to query the name of the MPM is a good reason. IMHO, the correct
way for somebody to get the name of the MPM, is to use the ServerString.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] mpm_query
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
From: <rb...@covalent.net>
Sent: Wednesday, April 11, 2001 12:39 PM
> On Wed, 11 Apr 2001, Sander van Zoest wrote:
>
> > The more accurate information you have in the noc the better. Why monitor
> > if you do not know what you are monitoring?
>
> The problem is that the MPM name is not accurate. We have a habit of
> changing names of things. The MPM properties are the best way to
> determine the behavior of the MPM IMNSHO.
100% correct that we need to test features (dynamically), not the arbitrary
name of some MPM.
Beyond that, there is nothing wrong with being informative :-)
Re: [PATCH] mpm_query
Posted by rb...@covalent.net.
On Wed, 11 Apr 2001, Harrie Hazewinkel wrote:
> rbb@covalent.net wrote:
> >
> > On Wed, 11 Apr 2001, Sander van Zoest wrote:
> >
> > > On Wed, 11 Apr 2001 rbb@covalent.net wrote:
> > >
> > > > I want to decouple the MPM query function from an actual name. The goal
> > > > should be to report the properties of the MPM, not which exact MPM was
> > > > used. Once that is done, the need for the string disappears.
> > >
> > > I would think you want to provide the actual name as well, on top of
> > > the properties. This probably could be listed just as APACHE_MPM_DIR which
> > > it could query the properties from the actual MPM via a common interface.
> > > Everything found in -V should be used for monitoring/logging.
> >
> > That value is already compiled into the server. But there is currently no
> > way to query it.
>
> Then it should be added somehow. :-))
I disagree. The name doesn't mean anything. How the MPM behaves is what
is important, not what it is called.
> > > What happens when you have incompatibility on a particular platform with
> > > a MPM? It shouldn't just segfault, there should be a way to exit cleanly
> > > explaining why this particular module or piece of code can not run with
> > > the MPM used and the platform.
> >
> > If there is a compatability problem between a platform and an MPM, then we
> > currently do not allow that MPM to be compiled on that platform without
> > direct intervention from the person compiling the server. For example, on
> > FreeBSD, we do not compile with threads unless the admin tells us we have
> > to.
> >
> > > The more accurate information you have in the noc the better. Why monitor
> > > if you do not know what you are monitoring?
> >
> > The problem is that the MPM name is not accurate. We have a habit of
> > changing names of things. The MPM properties are the best way to
> > determine the behavior of the MPM IMNSHO.
>
> Then Apache should start standardising there efforts, ASAP.
> Changing it is just a hell from management perspective.
> Each time when you upgrade a server you have to upgrade
> the management software (whatever that may be) should be
> upgraded to??
We have tried to standardize. The problem is that standardization is
almost never followed 100%. At one time all of the MPMs were supposed to
have a prefix that told whether it was multi-process or multi-threaded.
OS/2 did this correctly. Now, the standard has changed, so that there is
no easy way to determine from the name of the MPM what it's properties
are.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] mpm_query
Posted by Harrie Hazewinkel <ha...@covalent.net>.
rbb@covalent.net wrote:
>
> On Wed, 11 Apr 2001, Sander van Zoest wrote:
>
> > On Wed, 11 Apr 2001 rbb@covalent.net wrote:
> >
> > > I want to decouple the MPM query function from an actual name. The goal
> > > should be to report the properties of the MPM, not which exact MPM was
> > > used. Once that is done, the need for the string disappears.
> >
> > I would think you want to provide the actual name as well, on top of
> > the properties. This probably could be listed just as APACHE_MPM_DIR which
> > it could query the properties from the actual MPM via a common interface.
> > Everything found in -V should be used for monitoring/logging.
>
> That value is already compiled into the server. But there is currently no
> way to query it.
Then it should be added somehow. :-))
>
> > What happens when you have incompatibility on a particular platform with
> > a MPM? It shouldn't just segfault, there should be a way to exit cleanly
> > explaining why this particular module or piece of code can not run with
> > the MPM used and the platform.
>
> If there is a compatability problem between a platform and an MPM, then we
> currently do not allow that MPM to be compiled on that platform without
> direct intervention from the person compiling the server. For example, on
> FreeBSD, we do not compile with threads unless the admin tells us we have
> to.
>
> > The more accurate information you have in the noc the better. Why monitor
> > if you do not know what you are monitoring?
>
> The problem is that the MPM name is not accurate. We have a habit of
> changing names of things. The MPM properties are the best way to
> determine the behavior of the MPM IMNSHO.
Then Apache should start standardising there efforts, ASAP.
Changing it is just a hell from management perspective.
Each time when you upgrade a server you have to upgrade
the management software (whatever that may be) should be
upgraded to??
Harrie
--
phone: +39-3474932300
http://www.lisanza.net/
Re: [PATCH] mpm_query
Posted by Bill Stoddard <bi...@wstoddard.com>.
> On Wed, 11 Apr 2001, Sander van Zoest wrote:
>
> > On Wed, 11 Apr 2001 rbb@covalent.net wrote:
> >
> > > > What happens when you have incompatibility on a particular platform
with
> > > > a MPM? It shouldn't just segfault, there should be a way to exit
cleanly
> > > > explaining why this particular module or piece of code can not run
with
> > > > the MPM used and the platform.
> > > If there is a compatability problem between a platform and an MPM, then
we
> > > currently do not allow that MPM to be compiled on that platform without
> > > direct intervention from the person compiling the server. For example,
on
> > > FreeBSD, we do not compile with threads unless the admin tells us we
have
> > > to.
> >
> > Right, I guess I didn't really phrase my question the right way.
> > How would you determine this incompatibility if you are a DSO module
trying
> > run on Apache HTTP 2.0? Let say a module can only run on prefork, for
> > example.
>
> Modules that hard-code which MPMs they support based on name are broken.
> The name doesn't MEAN anything. Modules should be determining if they
> work based on the properties of the MPM.
Yep that's exactly what I think as well.
Bill
Re: [PATCH] mpm_query
Posted by Sander van Zoest <sa...@covalent.net>.
On Wed, 11 Apr 2001 rbb@covalent.net wrote:
> > Right, I guess I didn't really phrase my question the right way.
> > How would you determine this incompatibility if you are a DSO module trying
> > run on Apache HTTP 2.0? Let say a module can only run on prefork, for
> > example.
> Modules that hard-code which MPMs they support based on name are broken.
> The name doesn't MEAN anything. Modules should be determining if they
> work based on the properties of the MPM. Using the name means that they
> need to be modified and re-compiled whenever a new MPM is released. I am
> not interested in supporting broken modules, especially not when it is
> easier to support a working implementation.
I am not suggesting to use the name to determine compatibility, the name
is really just an identifier to what you would call the MPM in general
terms. I totally agree that the properties should be able to determine
compatibility.
I would say then that the properties of an MPM should be extensible and
flexible, because what happens when you have multiple types of threaded
MPMs on the same platform and such. We really can't determine all the
possible MPM properties that might exist in the future.
If you tell a user that they need a threaded MPM instead of a process based
MPM, then they need to somehow figure out the name of the MPM they want to
use as the threaded MPM when they recompile. An --enable-threads isn't good
enough. Are we talking pthreads, sgi's state threads etc.
> I have asked for how it is useful. I haven't heard an answer yet that
> can't be determined either from the extension I have suggested.
One place knowing the name of the MPM is useful is just to be able to
provide a way of quickly describing an MPM without necessarily describing
it by it's properties. If we do not allow for discovering the name
programmaticly then we would have to have a matrix somewhere that finds
out the name of the MPM just so people can quickly know which it is.
Think of it more like an ID, not necessarily a name that accurately describes
the MPM.
> > We should also keep in mind 3rd party MPMs such as the SGI STM MPM which
> > might accurately describe the MPM by it's name, but it is an identifier that
> > could point to the origin of the MPM.
>
> This is best determined by looking at the Server String. We are talking
> about how to programitically get this information. If you are looking for
> where the MPM came from, that should be in the server string, not
> retrieved from the MPM through the query interface. The query interface
> was designed to retrieve the run-time properties of the MPM.
So a logging module or monitoring interface should parse the Server
String to find out the name of the MPM? I really do not understand the
harm by allowing the name of the MPM to be programmaticly determined
without having to go through the hassle of parsing the Server String.
An ap_show_mpm_name() similar to ap_show_modules() and ap_show_directives()
seems to makes sense to me ontop of the mpm_query interface for properties.
--
Sander van Zoest [sander@covalent.net]
Covalent Technologies, Inc. http://www.covalent.net/
(415) 536-5218 http://Sander.vanZoest.com/
Re: [PATCH] mpm_query
Posted by rb...@covalent.net.
On Wed, 11 Apr 2001, Sander van Zoest wrote:
> On Wed, 11 Apr 2001 rbb@covalent.net wrote:
>
> > > What happens when you have incompatibility on a particular platform with
> > > a MPM? It shouldn't just segfault, there should be a way to exit cleanly
> > > explaining why this particular module or piece of code can not run with
> > > the MPM used and the platform.
> > If there is a compatability problem between a platform and an MPM, then we
> > currently do not allow that MPM to be compiled on that platform without
> > direct intervention from the person compiling the server. For example, on
> > FreeBSD, we do not compile with threads unless the admin tells us we have
> > to.
>
> Right, I guess I didn't really phrase my question the right way.
> How would you determine this incompatibility if you are a DSO module trying
> run on Apache HTTP 2.0? Let say a module can only run on prefork, for
> example.
Modules that hard-code which MPMs they support based on name are broken.
The name doesn't MEAN anything. Modules should be determining if they
work based on the properties of the MPM. Using the name means that they
need to be modified and re-compiled whenever a new MPM is released. I am
not interested in supporting broken modules, especially not when it is
easier to support a working implementation.
> > > The more accurate information you have in the noc the better. Why monitor
> > > if you do not know what you are monitoring?
> > The problem is that the MPM name is not accurate. We have a habit of
> > changing names of things. The MPM properties are the best way to
> > determine the behavior of the MPM IMNSHO.
>
> Just because the MPM name isn't an accurate discription of what the properties
> are of an MPM doesn't mean it could not useful to know what the MPM name is?
I have asked for how it is useful. I haven't heard an answer yet that
can't be determined either from the extension I have suggested.
> We should also keep in mind 3rd party MPMs such as the SGI STM MPM which
> might accurately describe the MPM by it's name, but it is an identifier that
> could point to the origin of the MPM.
This is best determined by looking at the Server String. We are talking
about how to programitically get this information. If you are looking for
where the MPM came from, that should be in the server string, not
retrieved from the MPM through the query interface. The query interface
was designed to retrieve the run-time properties of the MPM.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] mpm_query
Posted by Sander van Zoest <sa...@covalent.net>.
On Wed, 11 Apr 2001 rbb@covalent.net wrote:
> > What happens when you have incompatibility on a particular platform with
> > a MPM? It shouldn't just segfault, there should be a way to exit cleanly
> > explaining why this particular module or piece of code can not run with
> > the MPM used and the platform.
> If there is a compatability problem between a platform and an MPM, then we
> currently do not allow that MPM to be compiled on that platform without
> direct intervention from the person compiling the server. For example, on
> FreeBSD, we do not compile with threads unless the admin tells us we have
> to.
Right, I guess I didn't really phrase my question the right way.
How would you determine this incompatibility if you are a DSO module trying
run on Apache HTTP 2.0? Let say a module can only run on prefork, for
example.
> > The more accurate information you have in the noc the better. Why monitor
> > if you do not know what you are monitoring?
> The problem is that the MPM name is not accurate. We have a habit of
> changing names of things. The MPM properties are the best way to
> determine the behavior of the MPM IMNSHO.
Just because the MPM name isn't an accurate discription of what the properties
are of an MPM doesn't mean it could not useful to know what the MPM name is?
We should also keep in mind 3rd party MPMs such as the SGI STM MPM which
might accurately describe the MPM by it's name, but it is an identifier that
could point to the origin of the MPM.
--
Sander van Zoest [sander@covalent.net]
Covalent Technologies, Inc. http://www.covalent.net/
(415) 536-5218 http://Sander.vanZoest.com/
Re: [PATCH] mpm_query
Posted by rb...@covalent.net.
On Wed, 11 Apr 2001, Sander van Zoest wrote:
> On Wed, 11 Apr 2001 rbb@covalent.net wrote:
>
> > I want to decouple the MPM query function from an actual name. The goal
> > should be to report the properties of the MPM, not which exact MPM was
> > used. Once that is done, the need for the string disappears.
>
> I would think you want to provide the actual name as well, on top of
> the properties. This probably could be listed just as APACHE_MPM_DIR which
> it could query the properties from the actual MPM via a common interface.
> Everything found in -V should be used for monitoring/logging.
That value is already compiled into the server. But there is currently no
way to query it.
> What happens when you have incompatibility on a particular platform with
> a MPM? It shouldn't just segfault, there should be a way to exit cleanly
> explaining why this particular module or piece of code can not run with
> the MPM used and the platform.
If there is a compatability problem between a platform and an MPM, then we
currently do not allow that MPM to be compiled on that platform without
direct intervention from the person compiling the server. For example, on
FreeBSD, we do not compile with threads unless the admin tells us we have
to.
> The more accurate information you have in the noc the better. Why monitor
> if you do not know what you are monitoring?
The problem is that the MPM name is not accurate. We have a habit of
changing names of things. The MPM properties are the best way to
determine the behavior of the MPM IMNSHO.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] mpm_query
Posted by Sander van Zoest <sa...@covalent.net>.
On Wed, 11 Apr 2001 rbb@covalent.net wrote:
> I want to decouple the MPM query function from an actual name. The goal
> should be to report the properties of the MPM, not which exact MPM was
> used. Once that is done, the need for the string disappears.
I would think you want to provide the actual name as well, on top of
the properties. This probably could be listed just as APACHE_MPM_DIR which
it could query the properties from the actual MPM via a common interface.
Everything found in -V should be used for monitoring/logging.
What happens when you have incompatibility on a particular platform with
a MPM? It shouldn't just segfault, there should be a way to exit cleanly
explaining why this particular module or piece of code can not run with
the MPM used and the platform.
The more accurate information you have in the noc the better. Why monitor
if you do not know what you are monitoring?
--
Sander van Zoest [sander@covalent.net]
Covalent Technologies, Inc. http://www.covalent.net/
(415) 536-5218 http://Sander.vanZoest.com/
Re: [PATCH] mpm_query
Posted by rb...@covalent.net.
On Wed, 11 Apr 2001, Harrie Hazewinkel wrote:
> rbb@covalent.net wrote:
> > On Wed, 11 Apr 2001, dean gaudet wrote:
> > > On Wed, 11 Apr 2001 rbb@covalent.net wrote:
> > > > On Wed, 11 Apr 2001, Harrie Hazewinkel wrote:
> > > > > + /* The MPM types below should actually a string which enables better identification */
> > > > > + #define AP_MPMQ_BEOS 1 /* MPM:Beos */
> > > > > + #define AP_MPMQ_PERCHILD 2 /* MPM:perchild */
> > > > > + #define AP_MPMQ_PREFORK 3 /* MPM:prefork */
> > > > > + #define AP_MPMQ_SPMT_OS2 4 /* MPM:spmt_os2 */
> > > > > + #define AP_MPMQ_WINNT 5 /* MPM:winnt */
> > > > > + #define AP_MPMQ_THREADED 6 /* MPM:threaded */
> > > >
> > > > I dislike this. The Modules shouldn't care which MPM they are running on.
> > > > Why do we need this option?
>
> This option could be of interest to operators. With they could see
> what kind of MPM a perticular server in a server-farm uses.
> The way you retrieve this could be via a status page, SNMP, and others.
Why is this useful? Isn't it more useful to know whether it is threaded
or process based. Between that information and the OS, is that enough? I
would rather add information like THREADS_DYNAMIC or THREADS_STATIC and
PROCESSES_DYNAMIC or PROCESSES_STATIC, to basically say if the number of
threads/process is static or not, and if the number of processes is
static.
I want to decouple the MPM query function from an actual name. The goal
should be to report the properties of the MPM, not which exact MPM was
used. Once that is done, the need for the string disappears.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] mpm_query
Posted by Harrie Hazewinkel <ha...@covalent.net>.
rbb@covalent.net wrote:
>
> On Wed, 11 Apr 2001, dean gaudet wrote:
>
> > On Wed, 11 Apr 2001 rbb@covalent.net wrote:
> >
> > > On Wed, 11 Apr 2001, Harrie Hazewinkel wrote:
> > >
> > > > + /* The MPM types below should actually a string which enables better identification */
> > > > + #define AP_MPMQ_BEOS 1 /* MPM:Beos */
> > > > + #define AP_MPMQ_PERCHILD 2 /* MPM:perchild */
> > > > + #define AP_MPMQ_PREFORK 3 /* MPM:prefork */
> > > > + #define AP_MPMQ_SPMT_OS2 4 /* MPM:spmt_os2 */
> > > > + #define AP_MPMQ_WINNT 5 /* MPM:winnt */
> > > > + #define AP_MPMQ_THREADED 6 /* MPM:threaded */
> > >
> > > I dislike this. The Modules shouldn't care which MPM they are running on.
> > > Why do we need this option?
This option could be of interest to operators. With they could see
what kind of MPM a perticular server in a server-farm uses.
The way you retrieve this could be via a status page, SNMP, and others.
> >
> > not to mention that it should be a string based query instead of
> > hard-coded integers... otherwise it requires patching every time a new MPM
> > is added, which is wrong.
>
> I agree. Of course, a string would require a new query function, because
> the current one always returns an int. Or, we could abstract it out to
> return a void *.
Like my comment said. I just mapped it to an integer otherwise
the mpm_query should change too. It was a work-around based on the
current mpm_query, but a string is way better.
If we would change it into a 'void *' we maybe need also a length
parameter. Just to check whether the caller provides enough space
to return the value (int, string, etc..)
harrie
--
phone: +39-3474932300
http://www.lisanza.net/
Re: [PATCH] mpm_query
Posted by rb...@covalent.net.
On Wed, 11 Apr 2001, dean gaudet wrote:
> On Wed, 11 Apr 2001 rbb@covalent.net wrote:
>
> > On Wed, 11 Apr 2001, Harrie Hazewinkel wrote:
> >
> > > + /* The MPM types below should actually a string which enables better identification */
> > > + #define AP_MPMQ_BEOS 1 /* MPM:Beos */
> > > + #define AP_MPMQ_PERCHILD 2 /* MPM:perchild */
> > > + #define AP_MPMQ_PREFORK 3 /* MPM:prefork */
> > > + #define AP_MPMQ_SPMT_OS2 4 /* MPM:spmt_os2 */
> > > + #define AP_MPMQ_WINNT 5 /* MPM:winnt */
> > > + #define AP_MPMQ_THREADED 6 /* MPM:threaded */
> >
> > I dislike this. The Modules shouldn't care which MPM they are running on.
> > Why do we need this option?
>
> not to mention that it should be a string based query instead of
> hard-coded integers... otherwise it requires patching every time a new MPM
> is added, which is wrong.
I agree. Of course, a string would require a new query function, because
the current one always returns an int. Or, we could abstract it out to
return a void *.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] mpm_query
Posted by dean gaudet <dg...@arctic.org>.
On Wed, 11 Apr 2001 rbb@covalent.net wrote:
> On Wed, 11 Apr 2001, Harrie Hazewinkel wrote:
>
> > + /* The MPM types below should actually a string which enables better identification */
> > + #define AP_MPMQ_BEOS 1 /* MPM:Beos */
> > + #define AP_MPMQ_PERCHILD 2 /* MPM:perchild */
> > + #define AP_MPMQ_PREFORK 3 /* MPM:prefork */
> > + #define AP_MPMQ_SPMT_OS2 4 /* MPM:spmt_os2 */
> > + #define AP_MPMQ_WINNT 5 /* MPM:winnt */
> > + #define AP_MPMQ_THREADED 6 /* MPM:threaded */
>
> I dislike this. The Modules shouldn't care which MPM they are running on.
> Why do we need this option?
not to mention that it should be a string based query instead of
hard-coded integers... otherwise it requires patching every time a new MPM
is added, which is wrong.
-dean
Re: [PATCH] mpm_query
Posted by rb...@covalent.net.
On Wed, 11 Apr 2001, Harrie Hazewinkel wrote:
> HI,
>
> Attached is a patch that enables the mpm_query function
> to return more information. It returns for instance,
> the HARD_SERVER_LIMIT and HARD_THREAD_LIMIT.
>
> Note: I only was able to test it in the preforked
> MPM, due to my system I guess.
> apr_procattr_t *attr,
> apr_pool_t *p);
>
> + /* The MPM types below should actually a string which enables better identification */
> + #define AP_MPMQ_BEOS 1 /* MPM:Beos */
> + #define AP_MPMQ_PERCHILD 2 /* MPM:perchild */
> + #define AP_MPMQ_PREFORK 3 /* MPM:prefork */
> + #define AP_MPMQ_SPMT_OS2 4 /* MPM:spmt_os2 */
> + #define AP_MPMQ_WINNT 5 /* MPM:winnt */
> + #define AP_MPMQ_THREADED 6 /* MPM:threaded */
I dislike this. The Modules shouldn't care which MPM they are running on.
Why do we need this option? Other than that, the patch looks good. Could
oyu please generate unified patches from now on, they are much easier to
debug.
Ryan