calling methods from other modules
I want to call mod_transform_set_XSLT (from mod_transform) in my PerlResponseHandler. Is this possible? Generally speaking, can I use methods from other apache modules in my handlers? -- Marc Lambrichs
Re: high throughput perl server
Hi folks, Maybe I'm just a complete newbie to this or I completely do not understand what we're talking about here... :) ...but we've written a home-grown ad server that runs on Apache2/mod_perl2/PgSQL that serves up 40 or more ads per second (sustained) where each ad served includes 5-6 hits to the database. Some of this performance may have to do with the fact that the webserver and database server are separate boxes which balances load and memory usage. And we're not really doing anything special. Right now, it's implemented as a simple registry script which means we're not even using a custom PerlResponseHandler inside our httpd.conf. So I can call the script as mod_cgi or as mod_perl or even on the command line for debugging. Am I doing something wrong? :) --Joel >On 5/26/05, Perrin Harkins <[EMAIL PROTECTED]> wrote: >> On Thu, 2005-05-26 at 14:53 -0400, Erik Aronesty wrote: >> > ppcgid kicks it's butt in that arena. >> >> > My business partner and I decided on two tactics: he started >> > building a patch to thttpd to run perl scripts natively as opposed >> > to exec'ing, and I built a pure perl web server. I finished first, >> > so we're using that for now. But I think that a perl patch to >> > thttpd (including preloading support) is what we'll be using in the >> > long run... it's the right way to go. > >Me too -- mine is on CPAN as HTTP::Server::Singlethreaded, and apps >written against it that have to do DBI calls to serve each page are >responsive enough to deliver multiple pages per second. I am curious >to see which will be the choke point as more throughput is needed: the >MySQL server or the Singlethreaded. If it turns out that there are >delays due to ST waiting for DBI results, ST can be made to fork after >binding the listening ports, but DBI connections must be done after the >forking, as I understand it, at this time. Currently my ST >installation is handling my load perfectly well as a single thread. > >I haven't looked at ppcgid yet, I might lift some code out of it for ST >if it is licensed in a way conducive to that.
Problem with long POST parameter values in Apache::Request
Hi, I'm running into a problem with Apache::Request handling large POST values on a RedHat ES 3 system using libapreq-2.02-dev and the RH rpm package of apache (2.0.46-44.ent). The problem is that when a large value (say a memo entered into a textarea box) is received Apache::Request fails to extract it and any input parameters after it (as they appear in the request body) are also not extracted. It is as if Apache::Request ignores the large value and everything coming in after it. I'm fairly certain this is Apache::Request specific -- Apache::compat's handling of large values is fine on the same machine. Has anyone else observed this behavior? Does anyone know if this has been fixed in any of the later versions of libapreq2 ? I read over the changes log but didn't find anything that I could tell related to this issue. Thanks, Joel
Re: Apache Error Log Format
Daniel B. Hemmerich wrote:
Thanks for the good idea... it is a direction worth investigating
further. Until someone offers a potentially better solution, I will play
around with this and hopefully in the next few days report back on my
results!
Thanks again,
Daniel
Jonathan Vanasco wrote:
I really have no idea, but no one has chimed up on this, so I'll try
to help (and maybe someone here can clear up my misconceptions)
MP writes to STDERR, BUT things can get weird because of the way
apache2 handles error messages --
I could have this wrong, but mp errors and perl errors seem to go to
the main apache error log ( on my system that's
/usr/local/apache2/logs/error_log ).
When i specify a separate errorlog for a vhost, STDERR is directed there
I don't know how to accomplish what you want , but I think I can help
point you in a direction:
When I saw this post, i remembered how the default OSX apache2/mp had
a specific compile time option that didn't 'print' to apache -- i
think one had to call $r->print() instead of print, because of how
STDOUT was directed.
The 'fix' was either to recompile apache, or set up a perl handler
to tie STDOUT to Apache
I'm found a post about this on google (not sure if its the 'right'
one, i came across this 2 years ago):
http://www.macosxhints.com/article.php?story=20031129120521712
PerlHeaderParserHandler "sub { tie *STDOUT, 'Apache' unless
tied *STDOUT; }"
Based on that, i *think* that you could probably write a handler that
intercepts STDERR, rewrites it to your specifications, and
ties/redirects it somewhere
But , two things worry me about this:
a_ i'm not quite sure of the mechanics of the multiple log files
that apache can generate, and which one(s) would have what you want --
or how to intercept them
b_ i'm quite sure that there is a better way, that probably uses
more of the apache configuration powers of mod_perl, and not a crazy
hack like this
Again, I dont have much of an idea on this -- but no one else chimed
up and that tie to STDOUT really popped out in my memories when I read
this post.
On May 31, 2005, at 8:36 AM, Daniel B. Hemmerich wrote:
Hello all...
When a misconfiguration occurs, we receive a new line in the apache
error logs that is not in the standard error log format (I assume
since MP is writing to STDERR). Short of changing all of our scripts
to properly log, is there a quicker method to accomplish the
following change:
Change this:
Can't locate /www/path/goes/here//config.pl in @INC (@INC contains:
/usr/local/lib/perl5/5.8.4/i686-linux /usr/local/lib/perl5/5.8.4
/usr/local/lib/perl5/site_perl/5.8.4/i686-linux
/usr/local/lib/perl5/site_perl/5.8.4 /usr/local/lib/perl5/site_perl
.) at /www/example.com/cgi-bin/example.cgi line 64.
To this:
[Thu May 19 08:47:41 2005] [error] [MODULENAME Can't locate
/www/path/goes/here//config.pl in @INC (@INC contains:
/usr/local/lib/perl5/5.8.4/i686-linux /usr/local/lib/perl5/5.8.4
/usr/local/lib/perl5/site_perl/5.8.4/i686-linux
/usr/local/lib/perl5/site_perl/5.8.4 /usr/local/lib/perl5/site_perl
.) at /www/example.com/cgi-bin/example.cgi line 64.
Thanks in advance!
Maybe it has to do with this:
http://perl.apache.org/docs/2.0/user/install/install.html#Apache
-DAP_UNSAFE_ERROR_LOG_UNESCAPED
--
Arshavir Grigorian
Systems Administrator/Engineer
Re: Problem with long POST parameter values in Apache::Request
Joel Stevenson <[EMAIL PROTECTED]> writes: > Has anyone else observed this behavior? Does anyone know if this has > been fixed in any of the later versions of libapreq2 ? Yes and yes; 2.02-dev is absolutely ancient history. Apache::Request is called Apache2::Request nowadays; if you can't upgrade to 2.05-dev or svn trunk, use CGI.pm. -- Joe Schaefer
Re: Apache Error Log Format
That sounds more like the opposite...
I do want Apache to be prefixing each error message with its data...
Unless I misunderstood what that page was saying
Arshavir Grigorian wrote:
Daniel B. Hemmerich wrote:
Thanks for the good idea... it is a direction worth investigating
further. Until someone offers a potentially better solution, I will
play around with this and hopefully in the next few days report back
on my results!
Thanks again,
Daniel
Jonathan Vanasco wrote:
I really have no idea, but no one has chimed up on this, so I'll try
to help (and maybe someone here can clear up my misconceptions)
MP writes to STDERR, BUT things can get weird because of the way
apache2 handles error messages --
I could have this wrong, but mp errors and perl errors seem to go to
the main apache error log ( on my system that's
/usr/local/apache2/logs/error_log ).
When i specify a separate errorlog for a vhost, STDERR is directed there
I don't know how to accomplish what you want , but I think I can
help point you in a direction:
When I saw this post, i remembered how the default OSX apache2/mp had
a specific compile time option that didn't 'print' to apache -- i
think one had to call $r->print() instead of print, because of how
STDOUT was directed.
The 'fix' was either to recompile apache, or set up a perl
handler to tie STDOUT to Apache
I'm found a post about this on google (not sure if its the 'right'
one, i came across this 2 years ago):
http://www.macosxhints.com/article.php?story=20031129120521712
PerlHeaderParserHandler "sub { tie *STDOUT, 'Apache' unless
tied *STDOUT; }"
Based on that, i *think* that you could probably write a handler that
intercepts STDERR, rewrites it to your specifications, and
ties/redirects it somewhere
But , two things worry me about this:
a_ i'm not quite sure of the mechanics of the multiple log files
that apache can generate, and which one(s) would have what you want
-- or how to intercept them
b_ i'm quite sure that there is a better way, that probably uses
more of the apache configuration powers of mod_perl, and not a crazy
hack like this
Again, I dont have much of an idea on this -- but no one else chimed
up and that tie to STDOUT really popped out in my memories when I
read this post.
On May 31, 2005, at 8:36 AM, Daniel B. Hemmerich wrote:
Hello all...
When a misconfiguration occurs, we receive a new line in the apache
error logs that is not in the standard error log format (I assume
since MP is writing to STDERR). Short of changing all of our scripts
to properly log, is there a quicker method to accomplish the
following change:
Change this:
Can't locate /www/path/goes/here//config.pl in @INC (@INC contains:
/usr/local/lib/perl5/5.8.4/i686-linux /usr/local/lib/perl5/5.8.4
/usr/local/lib/perl5/site_perl/5.8.4/i686-linux
/usr/local/lib/perl5/site_perl/5.8.4 /usr/local/lib/perl5/site_perl
.) at /www/example.com/cgi-bin/example.cgi line 64.
To this:
[Thu May 19 08:47:41 2005] [error] [MODULENAME Can't locate
/www/path/goes/here//config.pl in @INC (@INC contains:
/usr/local/lib/perl5/5.8.4/i686-linux /usr/local/lib/perl5/5.8.4
/usr/local/lib/perl5/site_perl/5.8.4/i686-linux
/usr/local/lib/perl5/site_perl/5.8.4 /usr/local/lib/perl5/site_perl
.) at /www/example.com/cgi-bin/example.cgi line 64.
Thanks in advance!
Maybe it has to do with this:
http://perl.apache.org/docs/2.0/user/install/install.html#Apache
-DAP_UNSAFE_ERROR_LOG_UNESCAPED
Re: Apache2::Reload problem (ModPerl::Util bug)
Mark wrote:
> Mark wrote:
>
>> In 2.0.0, if there are heirarchical packages, and Apache2::Reload is
>> configured to reload the 'parent', it blows away the 'children' package
>> namespaces (and doesn't reload the children.) For example, if @INC has:
>>
>> Fubar.pm
>> Fubar/Child.pm
>>
>> And Apache2::Reload reloads package Fubar, it blows away
>> Fubar::Child::* and only reloads file Fubar.pm. Only a server
>> restart can recover from this point.
>>
>> The actual unloading work is done by ModPerl::Util::unload_package(),
>> whose behavior is contrary to the docs, which say:
>>
>> "unload_package()" takes care to leave sub-stashes intact while
>> deleting the requested stash. So for example if "CGI" and "CGI::Carp"
>> are loaded, calling "unload_package('CGI')" won't affect "CGI::Carp".
This is clearly a bug.
>> I only partly understand how unload_package() works, but it seems to
>> just iterate over symbols in the package and blow them away, without
>> regard for the actual file from which the symbol was instantiated.
Yup, it's that simple and there is a slightly smarter version in XS
that does check the source of the symbols from.
>> I tried modifying the code to skip over symbols that correspond
>> to a key in %INC, which seems logical and works correctly in my tests,
>> but may not be a complete or perfect solution for reasons beyond
>> my current testing/thinking. However, in my tests, it works correctly
>> if either the parent package, child package, or both are modified.
>>
>> Comments/suggestions about the correctness of this patch requested.
>
> Correction. Ignore previous patch. It only worked one level of
> heirarchy. Correct patch is:
Much simpler patch to just skip stashes has been checked in in rev 179448.
If you can try latest-svn and confirm your problem goes away, that would be
fantastic.
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
signature.asc
Description: OpenPGP digital signature
