Re: Apache calls initialize module twice
Jim Jagielski wrote: On Nov 13, 2003, at 2:43 PM, Jeff Trawick wrote: ap_mpm_query(), implemented by each MPM, would need some help from core to determine which pass of the pre/post-config hook it is, since that is out of the MPM's domain. It seems to me that the proposed patch (for modules) elegantly solves a problem that a significant percentage of modules have to worry about. I don't see why folding this into ap_mpm_query() is desirable when the "fix" already exists. I think you're saying the same thing... yeah :) I was "feeling" that there would not be a clean way to combine the two issues, but I was trying to make sense of such a combination since I thought wrowe was trying to pull both topics together :)
Re: Apache calls initialize module twice
On Nov 13, 2003, at 2:43 PM, Jeff Trawick wrote: ap_mpm_query(), implemented by each MPM, would need some help from core to determine which pass of the pre/post-config hook it is, since that is out of the MPM's domain. It seems to me that the proposed patch (for modules) elegantly solves a problem that a significant percentage of modules have to worry about. I don't see why folding this into ap_mpm_query() is desirable when the "fix" already exists. I think you're saying the same thing...
Re: Apache calls initialize module twice
Jeff Trawick wrote:
[...]
Since the work arounds (such as Bill suggested) are required for 1.3
and 2.0
compatiblity already, it seems we should focus on 2.1 and solve this
for good.
as far putting a solution in 2.0, what is it our concern if a module
wants to support only Apache >= 2.0.50? we may have our own modules
that need such an API enhancement
Yup, mod_perl 2.0 now requires 2.0.46 and will most likely shift that
requirement up with time. We can make this an optional feature, available only
when Apache has it.
We have a new facility, ap_mpm_query, which would be perfect for
answering
nuggets of wisdom such as;
* Running as a win32 service? Or detached console daemon?
* A parent process? (Pre-fork or never forking (e.g. win32?)
* Pre-startup config testing?
* Server generation? (This answers the 2nd, 3rd, 4th startup pass
question)
a check for is-terminating would be nice too... there's a nice mod_cgid
restart patch in 2.1-dev that needs a way to query whether the other
child checker got APR_OC_REASON_DEATH because the other child died on
its own or because it died because the server is terminating... right
now the logic uses ap_graceful_stop_signalled(), which is a dummy
function with prefork... with worker, ap_graceful_stop_signalled() works
well enough for the mod_cgid patch, but it doesn't distiguish between
graceful and ungraceful termination
If we add AP_MPMQ_QUERY_STATE request that returns one of
{AP_MPMQ_STATE_INITIALIZED, AP_MPMQ_STATE_INITIALIZING,
AP_MPMQ_STATE_GRACEFUL_STOP, AP_MPMQ_STATE_HARD_STOP}, modules ought to
be able to get some type of clue on the big picture, though that doesn't
help with which pass of the pre/post-config hook it is.
ap_mpm_query(), implemented by each MPM, would need some help from core
to determine which pass of the pre/post-config hook it is, since that is
out of the MPM's domain.
I must admit I don't understand the original initialize-module question
and how it relates to whether MPM is run with -X mode. Any clues? I
can see plain as day the pre-config/post-config issue in
server/main.c:main(). Without that understanding, I'm not sure what
sort of info sharing is needed between core and the MPM to allow module
to know whether or not this is the last time a certain hook will be
called during [re-]initialization.
There are two seemingly unrelated (ortogonal?) questions:
1. Are we parsing config for the first or the second time
2. Are we in one of the START|RESTART|GRACEFUL|STOP mode.
Only in the START mode a module needs to know whether its config hooks are run
for the first time or the second. In the rest of the modes it's always run
once (first time).
So depending on how you look it, the two can be related or not.
I think there should be two unrelated functions. One telling us whether we are
in first/second time config parsing (and I've posted a core patch for this).
The other telling us the operation mode (requires patching of all mpm
implementations).
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache calls initialize module twice
William A. Rowe, Jr. wrote:
At 02:18 PM 11/10/2003, you wrote:
Bill Stoddard wrote:
[...]
Any ideas how to avoid the second call to initalize_module when I run as a service ?
You can't avoid the second call but there are ways to gracefully handle it. Here is a snip of code from a module I developed a while back:
[...]
and I posted a patch which provides a generic API to do that. Since everybody is
replicating this code. And the thread has died w/o resolution. For some reason
http://marc.theaimsgroup.com doesn't have my original post, but only the rest of the
(unfinished) thread.
Stas,
Since the work arounds (such as Bill suggested) are required for 1.3 and 2.0
compatiblity already, it seems we should focus on 2.1 and solve this for good.
as far putting a solution in 2.0, what is it our concern if a module wants to
support only Apache >= 2.0.50? we may have our own modules that need such an
API enhancement
We have a new facility, ap_mpm_query, which would be perfect for answering
nuggets of wisdom such as;
* Running as a win32 service? Or detached console daemon?
* A parent process? (Pre-fork or never forking (e.g. win32?)
* Pre-startup config testing?
* Server generation? (This answers the 2nd, 3rd, 4th startup pass question)
a check for is-terminating would be nice too... there's a nice mod_cgid
restart patch in 2.1-dev that needs a way to query whether the other child
checker got APR_OC_REASON_DEATH because the other child died on its own or
because it died because the server is terminating... right now the logic uses
ap_graceful_stop_signalled(), which is a dummy function with prefork... with
worker, ap_graceful_stop_signalled() works well enough for the mod_cgid patch,
but it doesn't distiguish between graceful and ungraceful termination
If we add AP_MPMQ_QUERY_STATE request that returns one of
{AP_MPMQ_STATE_INITIALIZED, AP_MPMQ_STATE_INITIALIZING,
AP_MPMQ_STATE_GRACEFUL_STOP, AP_MPMQ_STATE_HARD_STOP}, modules ought to be able
to get some type of clue on the big picture, though that doesn't help with
which pass of the pre/post-config hook it is.
ap_mpm_query(), implemented by each MPM, would need some help from core to
determine which pass of the pre/post-config hook it is, since that is out of
the MPM's domain.
I must admit I don't understand the original initialize-module question and how
it relates to whether MPM is run with -X mode. Any clues? I can see plain as
day the pre-config/post-config issue in server/main.c:main(). Without that
understanding, I'm not sure what sort of info sharing is needed between core
and the MPM to allow module to know whether or not this is the last time a
certain hook will be called during [re-]initialization.
Re: Apache calls initialize module twice
William A. Rowe, Jr. wrote: At 02:18 PM 11/10/2003, you wrote: Bill Stoddard wrote: [...] Any ideas how to avoid the second call to initalize_module when I run as a service ? You can't avoid the second call but there are ways to gracefully handle it. Here is a snip of code from a module I developed a while back: [...] and I posted a patch which provides a generic API to do that. Since everybody is replicating this code. And the thread has died w/o resolution. For some reason http://marc.theaimsgroup.com doesn't have my original post, but only the rest of the (unfinished) thread. Stas, Since the work arounds (such as Bill suggested) are required for 1.3 and 2.0 compatiblity already, it seems we should focus on 2.1 and solve this for good. 1.3 has some sort of facility to know when restart happens. But we do need it for 2.0 as well. Why can't it be provided in 2.0 as well? We have a new facility, ap_mpm_query, which would be perfect for answering nuggets of wisdom such as; 1) Running as a win32 service? Or detached console daemon? 2) A parent process? (Pre-fork or never forking (e.g. win32?) 3) Pre-startup config testing? 4) Server generation? (This answers the 2nd, 3rd, 4th startup pass question) These sorts of answers are useful to alot of modules, but we don't need a new callback to add them - simply build upon the ap_mpm_query() options. [I've changed * bullets to numberical bullets above] I think all but the 3rd item fit the bill. pre-startup config happens in the core (main) and not in the mpm code and not specific to the mpm implementation. Do you still think it belongs to ap_mpm_query? I agree with 1, 2 and 4. Regarding 4, should it return a AP_MPM_ACTION_(START|RESTART|GRACEFUL|STOP) value (all 4 need to be defined if they aren't already) __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache calls initialize module twice
At 02:18 PM 11/10/2003, you wrote: >Bill Stoddard wrote: >[...] >>>Any ideas how to avoid the second call to initalize_module when I run as a >>> service ? > > >>You can't avoid the second call but there are ways to gracefully handle it. Here is >>a snip of code from a module I developed a while back: >[...] >and I posted a patch which provides a generic API to do that. Since everybody is >replicating this code. And the thread has died w/o resolution. For some reason >http://marc.theaimsgroup.com doesn't have my original post, but only the rest of the >(unfinished) thread. Stas, Since the work arounds (such as Bill suggested) are required for 1.3 and 2.0 compatiblity already, it seems we should focus on 2.1 and solve this for good. We have a new facility, ap_mpm_query, which would be perfect for answering nuggets of wisdom such as; * Running as a win32 service? Or detached console daemon? * A parent process? (Pre-fork or never forking (e.g. win32?) * Pre-startup config testing? * Server generation? (This answers the 2nd, 3rd, 4th startup pass question) These sorts of answers are useful to alot of modules, but we don't need a new callback to add them - simply build upon the ap_mpm_query() options. Bill
Re: Apache calls initialize module twice
Bill Stoddard wrote: [...] Any ideas how to avoid the second call to initalize_module when I run as a service ? You can't avoid the second call but there are ways to gracefully handle it. Here is a snip of code from a module I developed a while back: [...] and I posted a patch which provides a generic API to do that. Since everybody is replicating this code. And the thread has died w/o resolution. For some reason http://marc.theaimsgroup.com doesn't have my original post, but only the rest of the (unfinished) thread. Can we resolve this issue? Then I posted a related suggestion http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=106703058816859&w=2 which also died out unresolved ;( __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache calls initialize module twice
Nasko wrote:
Hello guys.
I'm running Apache2 on WindowsXP as a service (path to executable =
"c:\apache2\Apache.exe" -k runservice in my service configuration ) .
I have also
ap_hook_post_config (initialize_module, NULL,NULL,APR_HOOK_MIDDLE ) in
my source code...
The problem I have is that when run as a service initalize_module()
is called twice.
However when I debug in Visual C++ and call Apache2 with -X ,
initalize_module() is called only once
Any ideas how to avoid the second call to initalize_module when I
run as a service ?
Thanks in advance,
Nasko
You can't avoid the second call but there are ways to gracefully handle
it. Here is a snip of code from a module I developed a while back:
/* Run post_config only on the second config pass */
void *data;
apr_pool_userdata_get(&data, userdata_key, s->process->pool);
if (!data) {
apr_pool_userdata_set((const void *)1, userdata_key,
apr_pool_cleanup_null, s->process->pool);
return OK;
}
#ifdef WIN32
/* Do not run post_config in the Windows parent process
* The envar AP_PARENT_PID is set in the env list (by mpm_winnt)
* for the child process.
* **WARNING**:
* This check is not as robust as I would like because the name of
this
* envar is subject to change from release to release.
*/
if (!getenv("AP_PARENT_PID")) {
return OK;
}
#endif
This code actually does two things:
1. only allows post_config to run on the -second- pass (you can easily
tweak the code to make your hook run only on the first pass), and
2. only run post_config in the child process on Windows.
The second check is useful if your hook needs to allocate a lot of
resources; any resources you allocate in the Windows parent process are
probably not used or needed.
Bill
Apache calls initialize module twice
Hello guys. I'm running Apache2 on WindowsXP as a service (path to executable = "c:\apache2\Apache.exe" -k runservice in my service configuration ) . I have also ap_hook_post_config (initialize_module, NULL,NULL,APR_HOOK_MIDDLE ) in my source code... The problem I have is that when run as a service initalize_module() is called twice. However when I debug in Visual C++ and call Apache2 with -X , initalize_module() is called only once Any ideas how to avoid the second call to initalize_module when I run as a service ? Thanks in advance, Nasko
