Re: Apache start/restart nuances (was Re: [mp2] Custom directives)
> They aren't yet available in mp2, mostly due to the fact > that they weren't available in the Apache API until recently, and from > what Geoff has mentioned it seems to be incomplete yet. Geoff, what's > the current status of these query flags? I wasn't following cvs commits > for quite some time. I've tried the new query flags added recently (you > need cvs modperl and cvs apache to get them): they appear to be in 2.0 HEAD (APACHE_2_0_BRANCH) for all mpms. I know that jeff started with worker and prefork, so if there are any gaps I would expect them to be elsewhere. FWIW, they also appear to be in 2.0.49, having been introduced in worker this past december. so it may not be long before we can officially support them, but it will be a while - we're currently supporting 2.0.46, and I'd suggest to move to 2.0.47 soonish, but 2.0.49 as the minimum is pretty far off. but perhaps we can work support in gradually. the way you get these is just by querying ap_mpm_query for a new state (AP_MPMQ_MPM_STATE). most (if not all) mpms return APR_ENOTIMPL for an unknown query, so if we simply provided the required constant definitions we could probably open it all up now - on platforms where it isn't supported Apache::MPM::query would just return APR::ENOTIMPL instead of Apache::MPMQ_STARTING. --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Custom directives
> I have no idea where 'c' is coming from--like I said, I've instrumented
> {SERVER,DIR}_{CREATE,MERGE}, which I think should cover everything.
actually, probably too much :)
you haven't replied to my email yet, where it looks to me like some of your
directives are coming through just fine, but that got me thinking...
you sayid at the start that you have created one per-server directive and
several per-directory directives. you understand that the per-server and
per-dir object are different object, right? that ones created with
DIR_CREATE are not part of the SERVER_MERGE process so they will not show up
in the per-server object, even if they are used on a per-server level?
the rules to follow for custom directives wrt merging are this
- if you have only one directive, you do not need to write _any_ merge
routines
- if you define _both_ per-server _and_ per-directory directives then you
need to write _only_ DIR_CREATE and DIR_MERGE (though you can maintain them
separately from per-server directives if you wish).
- if you define _only_ per-server directives then you _should_ use
SERVER_CREATE and SERVER_MERGE (but the DIR_ equivalents will work as well,
they just add overhead).
the reasons for the later two rules are outlined at the end of recipe 7.10
http://www.modperlcookbook.org/chapters/ch07.pdf
unfortunately, the first rule didn't sink in until after the book came out,
so the example in 7.11 doesn't actually need the per-dir merging foo.
whether you are using mp1 or mp2, the stuff in chapter 7 is pretty valuable
if you're doing custom directive work. more equally valuable resources can
be found under the "More Information" header at the end of this article:
http://www.perl.com/pub/a/2003/07/08/mod_perl.html?page=3
HTH
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache start/restart nuances (was Re: [mp2] Custom directives)
Geoffrey Young wrote: They aren't yet available in mp2, mostly due to the fact that they weren't available in the Apache API until recently, and from what Geoff has mentioned it seems to be incomplete yet. Geoff, what's the current status of these query flags? I wasn't following cvs commits for quite some time. I've tried the new query flags added recently (you need cvs modperl and cvs apache to get them): they appear to be in 2.0 HEAD (APACHE_2_0_BRANCH) for all mpms. I know that jeff started with worker and prefork, so if there are any gaps I would expect them to be elsewhere. FWIW, they also appear to be in 2.0.49, having been introduced in worker this past december. so it may not be long before we can officially support them, but it will be a while - we're currently supporting 2.0.46, and I'd suggest to move to 2.0.47 soonish, but 2.0.49 as the minimum is pretty far off. Thanks Geoff. We could provide our own flag meanwhile, using the pool user data trick. Or we could expose the API to users, so they can do it in perl. It probably should be a function and not a variable/constant, so that when Apache catches up and provides such support we will internally switch to it. but perhaps we can work support in gradually. the way you get these is just by querying ap_mpm_query for a new state (AP_MPMQ_MPM_STATE). most (if not all) mpms return APR_ENOTIMPL for an unknown query, so if we simply provided the required constant definitions we could probably open it all up now - on platforms where it isn't supported Apache::MPM::query would just return APR::ENOTIMPL instead of Apache::MPMQ_STARTING. Hmm, have you by chance missed that I actually wrote the code that does that in the message that this reply goes to? And as I show there, it doesn't work. Please see my original (previous) post. thanks. -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache start/restart nuances (was Re: [mp2] Custom directives)
> Hmm, have you by chance missed that I actually wrote the code that does > that in the message that this reply goes to? And as I show there, it > doesn't work. Please see my original (previous) post. thanks. sorry, I guess I was answering a different question. :) I thought you were asking about the MPMQ_STATE query proper and if we could support the API across the board. whether the quI have no idea (versus starting and running), well I guess you've proven it doesn't, so I guess it's of no use to you for the issue at hand. but that's separate from whether we can support a state query with the next mp2 release, so that when httpd supports a real distinction people using a recent httpd can find out the info they need. --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache start/restart nuances (was Re: [mp2] Custom directives)
Geoffrey Young wrote: Hmm, have you by chance missed that I actually wrote the code that does that in the message that this reply goes to? And as I show there, it doesn't work. Please see my original (previous) post. thanks. sorry, I guess I was answering a different question. :) :) I thought you were asking about the MPMQ_STATE query proper and if we could support the API across the board. whether the quI have no idea (versus ? starting and running), well I guess you've proven it doesn't, so I guess it's of no use to you for the issue at hand. but that's separate from whether we can support a state query with the next mp2 release, so that when httpd supports a real distinction people using a recent httpd can find out the info they need. Well, it's supported already, the source scan has picked it and with a few tweaks it's conditioned to work where available. We just don't advertise it till it's supported by the minimal required Apache version. Since MPMQ_STATE doesn't satisfy Brent's quest, I suggest not to worry about it now. -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Apache v2 & ModPerl v1.99 build / install
I have tried using the source distros of Apache 2.0.49 & ModPerl 1.99.13. I have also tried pulling the latest dev releases of Apache & ModPerl from CVS. In both instances I get the following error attempting to start Apache: $ make test Syntax error on line 12 of ~/httpd.conf: Cannot load ~/mod_perl.so into server: ~/mod_perl.so: undefined symbol: PL_localizing" $ nm mod_perl.so | grep PL_localizing U PL_localizing Ideally I would like to use Apache 2.0.49 with ModPerl v2 (or 1.99.x as it stands). Is there something simple that I am doing wrong? Is there a general rule as to which versions of ModPerl we should be using with 2.0.49? Thanks for in advance for any assistance. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache v2 & ModPerl v1.99 build / install
Keith Tingle wrote: I have tried using the source distros of Apache 2.0.49 & ModPerl 1.99.13. I have also tried pulling the latest dev releases of Apache & ModPerl from CVS. In both instances I get the following error attempting to start Apache: $ make test Syntax error on line 12 of ~/httpd.conf: Cannot load ~/mod_perl.so into server: ~/mod_perl.so: undefined symbol: PL_localizing" $ nm mod_perl.so | grep PL_localizing U PL_localizing ldd mod_perl.so and nm libperl.so that mod_perl.so links to. Most likely you have more than one version of libperl.so on your system, and the wrong one is found. But see below. Ideally I would like to use Apache 2.0.49 with ModPerl v2 (or 1.99.x as it stands). Is there something simple that I am doing wrong? Is there a general rule as to which versions of ModPerl we should be using with 2.0.49? Thanks for in advance for any assistance. Please submit a proper bug report: http://perl.apache.org/bugs/ -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: environment not getting reset
Alex Krohn wrote:
Hi,
I'm facing a weird problem that's proving difficult to track down.
After a certain number of hits to our mod_perl apps, the environment no
longer gets reset per request. For example, if you have a script that
just dumps the environment, after hitting some piece of code, that
script will show PATH_INFO from a previous request (only when you don't
pass any path_info in, if you do pass it in, it shows the proper one).
This is weird... basically you're saying that when a given
$ENV{PATH_INFO} value should be undef, it uses the previous one?
I remember when I was working with you guys we had that custom CGI lib
which you wrote (was it GT::CGI?).
Could there be something strange going on at this level?
Have you greped your application for $ENV, see if you're not setting it
manually anywhere?
Have you tried to run the same app with another library such as CGI.pm?
Cheers,
--
Jean-Michel Hiver - MKDoc Ltd
http://mkdoc.com/
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Fwd: Re: some children not returning newly-inserted data
On Mon, 2004-05-17 at 18:55, Dave Boodman wrote:
> OK, here's some small(er) code I that repeats the problem.
Dave, this is really too much code, at least for me. It also refers to
lots more code that isn't shown here. If you go through the process of
reducing all of this to a small and complete example that illustrates
the bug, you will probably find the solution in the process.
> # process updates
> foreach my $obj (@toupdate) {
> $self->model->log('info', "updating obj:");
> $self->model->log_dumper('info', $obj);
> eval { $obj->update };
> if ($@) {
> $self->model->log('info', 'update failed, rolling back');
> foreach my $o (@created) { $o->dbi_rollback; }
> $self->context->throw( 'update', $@ );
> } else {
> push @created, $obj;
> }
> }
>
> # if we made it this far, commit everything
> foreach my $obj (@toupdate) { $obj->dbi_commit; }
> foreach my $obj (@created) { $obj->dbi_commit; }
Those dbi_rollback and dbi_commit calls don't do what you're thinking
they do. Transactions are database-wide, so the first rollback or
commit affects everything and anything after that is just wasted.
> You can see that when I try to retrieve the new customer, the # of
> hashes (the number of items the customer has) returned differs
> depending on the PID of the child. (All children should be returning
> 2)
If you run httpd with the -X flag, you may be able to come up with a
series of steps to reproduce this error reliably. That will allow you
to debug it using normal methods.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Help needed with mod_perl-1.99_13 and loading some AWStats modules
Hi! I'm trying to get some help in figuring out why I'm having problems with some AWStats perl modules in my Apache 2.0.48 (worker MPM)/mod_perl-1.99_13/Perl 5.8.2 (multi-threaded) on Redhat 9 Linux environment. Here is a link to the AWStats weblog analyzer: http://awstats.sourceforge.net/ Basically, AWStats uses Perl modules that get loaded at runtime to handle some functions, like displaying icons for identified browsers or flag icons of identified countries, etc. Intermittently, these modules behave incorrectly and the expected icons don't appear. I've contacted the AWStats author (the main developer at least) about this and he's thinking it's an issue with mod_perl. I don't know if he's right but I'm coming here to see if this is the case or not. :) Here are his comments: " If sometimes flags are here, problem is in loading the domains.pm (making country array not loaded correctly) file. Because yo use mod_perl and i known this module has a very special way to load pm files and to initialize perl variables (variables are kept in memory between sessions and not reloaded at each load of awstats page), i think problem comes from mod_perl. The DomainsHashIDLib array seems to be not always loaded by mod_perl but i don't know how to solve this." Here is a link to the thread in question: http://sourceforge.net/forum/message.php?msg_id=2571309 So, how can I determine what the cause of this intermittent behavior is? Could it be a problem with the main AWStats Perl script itself or somehing local to the Perl modules themselves? I have no idea where to begin tracking this down so ANY help would be greatly appreciated. Thanks Peace. Tom -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Help needed with mod_perl-1.99_13 and loading some AWStats modules
Tom Williams wrote: " If sometimes flags are here, problem is in loading the domains.pm (making country array not loaded correctly) file. Because yo use mod_perl and i known this module has a very special way to load pm files and to initialize perl variables (variables are kept in memory between sessions and not reloaded at each load of awstats page), i think problem comes from mod_perl. The DomainsHashIDLib array seems to be not always loaded by mod_perl but i don't know how to solve this." Actually, mod_perl is not doing anything special here. Perl normally keeps things in memory after you've compiled them, for as long as the interpreter is alive. You don't typically see the consequences of this because with a CGI script the perl interpreter exits right away, taking everything it had in memory with it. The problem with domains.pm is that it doesn't follow the rules for Perl5 modules: it has no package declaration. This causes you to hit the problem documented here: http://perl.apache.org/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs You may be able to make it work by running it under Apache::PerlRun, which is slower, but tries harder to support legacy code with namespace problems. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Help needed with mod_perl-1.99_13 and loading some AWStats modules
Perrin Harkins wrote: Tom Williams wrote: " If sometimes flags are here, problem is in loading the domains.pm (making country array not loaded correctly) file. Because yo use mod_perl and i known this module has a very special way to load pm files and to initialize perl variables (variables are kept in memory between sessions and not reloaded at each load of awstats page), i think problem comes from mod_perl. The DomainsHashIDLib array seems to be not always loaded by mod_perl but i don't know how to solve this." Actually, mod_perl is not doing anything special here. Perl normally keeps things in memory after you've compiled them, for as long as the interpreter is alive. You don't typically see the consequences of this because with a CGI script the perl interpreter exits right away, taking everything it had in memory with it. Cool! I do notice that from time to time the multi-threaded child processes will die off and new ones spawn and I understand this is normal for the Apache 2.0 work MPM. So, each time a child process terminates the Perl interpreter for that process goes with it and the new child gets a new interpreter, correct? The problem with domains.pm is that it doesn't follow the rules for Perl5 modules: it has no package declaration. This causes you to hit the problem documented here: http://perl.apache.org/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs Ok, I'll look into this. You may be able to make it work by running it under Apache::PerlRun, which is slower, but tries harder to support legacy code with namespace problems. Great! Thanks! Peace... Tom -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
