We need help from mod_perl users with technical expertise in non-mainstreamOSs
Here at the list we have a rather sucky trend in the last year or so. Those folks who report problems that they have on platforms that aren't *BSD, Linux and Win32 mostly get unasnwered. Doug, who seems to know about everything, used to respond to those souls, but nowadays he's too busy with real work. We have plenty of folks who are kind enough to help others with Linux, BSD flavors and Win32. So we are all dandy on these platforms. So, my big request is to all the folks on the other platforms, whose users don't get their problems resolved here. If somebody posts a problem that happens on the platform that you use, please try to help that person, even if you don't consider yourself an expert. Many times a participation in the person's quest helps him to find the way on its own. What bugs most people is the silence. Also if you know somebody who may know the answer but not on the list, please take the initiative and try to kindly ask that person to help. And who knows may be he will enjoy to help and do that in the future as well. Please, stop lurking in the shades, but try to help when you see that nobody else does. Especially if you were helped here before. Remember that you have to give back, if everybody becomes a leech there will be no blood left. Also remember that helping others is addictive, you just need to start doing that. Also remember that we all do mistakes. And we aren't experts in all fields. So if your answer is incorrect, it's not a big problem, since surprisingly, someone, who ignores the original question in first place, immediately posts to correct you. Don't feel bad about that, since you've just learned something. On the opposite feel good about your follow-up, because you tried to help. So, if my rant wakes anybody out there on SunOS, can you please try to figure out what the problem is with Kenny Smith's report: http://mathforum.org/epigone/modperl/sleikrigroo There are many earlier questions that went unanswered, just go to http://mathforum.org/epigone/modperl and see which posts have no followup, and try to help. It's better late, then never. __ 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: mod_perl 2.0 trouble compiling = cannont find -lapr -laprutil
So, I have updated my src of apache, arp and mod_perl2 from cvs. Still the exact same result. I've messed up while adjusting for the new libapr's naming. it's fixed now in cvs. Though you shouldn't have had a problem in first place. it'd have just skipped linking to the apr libs and shouldn't have caused a problem. In any case. Please update your cvs version and try again. If you fail, please check that you build against the new versions that you have installed. that's make sure that you've deleted all the old installs, if they are no longer needed. If you still fail, post a complete report as explained here: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems __ 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: Problems with Apache::compat and german special chars
[perl.apache.org keeps on timing out once in a while :( reposting]
Tom Schindl wrote:
Problems with Apache::compat
CGI-PARAM-STRING: header=%DC%DC%DC%DCbody=%D6%D6%D6%D6type=save_thread
cut--
[Sun Dec 08 21:39:09 2002] [error] [client 127.0.0.1] Character in c
format wrapped at
/usr/bestsolution/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache2/Apache/compat.pm
line 217.
, referer: http://localhost/discussion-board
cut--
When I copy the lines of interest into a small perl program and execute
it, everything works perfectly. What's going wrong there?
cut--
map { s/%([0-9a-fA-F]{2})/pack(c,hex($1))/ge; $_; } split /[=;]/,
$string, -1
cut--
Doug has fixed this already in the cvs version of mod_perl. Ditto for the
s/+/ / transform:
revision 1.71
date: 2002/11/23 22:35:06; author: dougm; state: Exp; lines: +2 -0
PR:
Obtained from:
Submitted by: Walery Studennikov [EMAIL PROTECTED]
Reviewed by: dougm
tr/+/ /; in parse_args compat method
revision 1.70
date: 2002/10/21 20:21:34; author: dougm; state: Exp; lines: +1 -1
PR:
Obtained from:
Submitted by: Walery Studennikov [EMAIL PROTECTED]
Reviewed by:dougm
fix parse_args compat method to support non-ascii characters
The problem was that the buggy code was doing pack(c, $num) which
expects a
number in range -128..127, whereas a fixed version does pack(C, $num),
which works with 0..255.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [mp2] Byterange requests
Nathan Byrd wrote: Hi all, I'm currently attempting to upgrade Apache::PAR to work with mod_perl 2, and one of the issues I am running into is with byterange requests: With mod_perl 1.x, it was possible (using Apache::File) to use byteranges with requests using $r-each_byterange and $r-set_byterange (a good example is in the mod_perl Developer's Cookbook, section 6.7, Byteserving and Range Requests.) It appears that with Apache2/mod_perl2 ap_each_byterange and ap_set_byterange are no longer available, replaced instead by a protocol filter in Apache. The only documentation for Apache I could find regarding this is at http://httpd.apache.org/docs-2.0/developer/filters.html - in that document, it explains that Byterange: We have coded it to be inserted for all requests, and it is removed if not used. Does anyone know if the above statement includes mod_perl requests, or is there another workaround to send byterange responses with mod_perl modules? I suppose it could be implemented in the module itself (or as a patch to mod_perl, maybe in Apache::Response), but I don't want to attempt that if the byterange filter could be run anyway for a request. I've read the ap_byterange_filter() code (modules/http/http_protocol.c) and it has all the bytecode functionality in that function, plus a helper ap_set_byterange, which is private to that filter, so it can't be used by mod_perl. If I understand correctly the benefits of slicing the response in the response handler is good if it somehow saves memory/CPU cycles. Otherwise byterange_filter will do that work for you. It looks like implementing this functionality as a third party module is a good idea. Mostly likely you can simply rip off the code from ap_byterange_filter, making it more modular and then adding the XS to have the perl api. Or you can write the whole thing in perl. I think all the ingredients are readily available. __ 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: [mp2] make install quirk
Randy Kobes wrote:
On Sat, 14 Dec 2002, Stas Bekman wrote:
[looks my original reply didn't make it through, trying again]
Beau E. Cox wrote:
Hi -
I am posting this message informally - this is not
critical (maybe not worth looking at); during
the mp2 make install, mod_perl.so is copied to the
apache2 tree (on my system) like this:
cp mod_perl.so /usr/local/apache2/modules
Now, if you haven't configured any apache2 modules
(as I haven't for my test server), the subdirectory
modules doesn't exist, so mod_perl.so is put into
the apache2 tree as _file_ 'modules' under
/usr/local/apache2. That's why I couldn't find it!
[...]
This is a known problem. I came up with this patch:
http://marc.theaimsgroup.com/?l=apache-modperl-devm=103847596809386w=2
But I'm afraid it's not portable and hence I couldn't commit it. Here is the
relevant snippet of the patch:
install:
+ test -d $(MODPERL_AP_LIBEXECDIR) || mkdir $(MODPERL_AP_LIBEXECDIR)
$(MODPERL_TEST_F) $(MODPERL_LIB_DSO) \
$(MODPERL_CP) $(MODPERL_LIB_DSO) $(MODPERL_AP_LIBEXECDIR)
Any portability gurus know how to make this Makefile's line (the one with +)
portable? I think 'mkdir' is portable. What about 'test -d'?
On Win32, at least, 'test' isn't available. What about something
like the following:
perl -e exit ! -d \$(MODPERL_AP_LIBEXECDIR)\ || mkdir $(...)
(the \ may be needed if the directory contains spaces, as Win32
might). And if one is worried about the system mkdir
availability, one can use
perl -MExtUtils::Command -e mkpath directory
randy++!
Please check that this work for you and I'll commit it (verified on linux).
You need to run a full build to check, unless you patch the Makefile manually.
I also see that my copy-n-paste has translated \t into spaces, so replace
those with tabs (between the + and $)
I've replaced \\ with qq{} because shells and quotes, even escaped ones are
a big trouble. At least your suggestion didn't work for me. qq{} works just fine.
Index: lib/Apache/Build.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v
retrieving revision 1.108
diff -u -r1.108 Build.pm
--- lib/Apache/Build.pm 28 Nov 2002 16:31:36 - 1.108
+++ lib/Apache/Build.pm 14 Dec 2002 08:43:32 -
@@ -1057,6 +1057,9 @@
lib: $(MODPERL_LIB)
install:
+ $(MODPERL_PERLPATH) -e exit ! -d qq{$(MODPERL_AP_LIBEXECDIR)} || \
+ $(MODPERL_PERLPATH) -MExtUtils::Command \
+ -e mkpath $(MODPERL_AP_LIBEXECDIR)
$(MODPERL_TEST_F) $(MODPERL_LIB_DSO) \
$(MODPERL_CP) $(MODPERL_LIB_DSO) $(MODPERL_AP_LIBEXECDIR)
__
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: mod_perl 2.0 trouble compiling = cannont find -lapr -laprutil
D. Fairbanks wrote: [...] LD_RUN_PATH=/usr/lib gcc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/Apache2/auto/APR/APR.so -L/usr/local/apache2/2.0.43/lib -lapr -laprutil /usr/bin/ld: cannot find -lapr collect2: ld returned 1 exit status make[3]: *** [../../../blib/arch/Apache2/auto/APR/APR.so] Error 1 [...] I've read the dialog between Benny Jensen and Stas Bekman from: [EMAIL PROTECTED]">http://mathforum.org/epigone/modperl/tendprerplu/[EMAIL PROTECTED] I've checked my Apache/Perl install three times against: http://perl.apache.org/docs/2.0/user/install/install.html#Condiguring_and_In stalling_Prerequisites And I've had an Apache Head check my installs, configs, versions, lib's processes. So far everything checks out fine. !?! But, mod-perl still won't compile and neither will apr-util. As repeated many times here, mod_perl builds on top of other components that just keep on changing (one of the reasons why a production mod_perl can't be released). So if you take a released version of mod_perl, it *will* build and work with the apr/apache released at about the same date. If you use any later releases/cvs of these components and a new version of mod_perl wasn't yet released, you *must* use the cvs version of mod_perl, as it adjusts on the go to the latest changes in the components it uses. In short, you need the latest mod_perl from cvs. http://perl.apache.org/docs/2.0/user/install/install.html#Installing_mod_perl_from_Source (scroll down to the CVS Bleeding-Edge Version) re: problems with building apr, email the apr list directly. ______ 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: Stupid newbie question: where is .?
Stephen Walton wrote: Please state [mp2] or something in the subject or at least in the message so we don't have to guess what version you are talking about. So, I'm using mod_perl as installed via RPMS on RedHat 8.0, and can't believe that an hour of hunting hasn't netted an answer to this apparently simple problem. Perl scripts seem not to have . set to ~user/public_html, as use() and require() fail on files which are in the same directory as the CGI script. What have I missed? The error message states that . is in @INC. To be specific, I've enabled mod_perl for ~user's files like this: Directory /home/user/public_html Options +Includes +ExecCGI AddHandler perl-script .pl PerlHandler ModPerl::Registry::handler PerlOptions +ParseHeaders /Directory Yes, ModPerl::Registry does *not* chdir to the script's dir in 2.0. Here is why: http://perl.apache.org/docs/2.0/user/coding/coding.html#Threads_Coding_Issues_under_mod_perl Various workarounds were discussed, but none were implemented so far. By the time mod_perl 2.0 is released we should sort it out. For now use mod_perl 1.0 if that's an issue to you. Of course you are more than welcome to sort this problem out and submit a patch for 2.0. __ 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: [mp2] make install quirk
[looks my original reply didn't make it through, trying again] Beau E. Cox wrote: Hi - I am posting this message informally - this is not critical (maybe not worth looking at); during the mp2 make install, mod_perl.so is copied to the apache2 tree (on my system) like this: cp mod_perl.so /usr/local/apache2/modules Now, if you haven't configured any apache2 modules (as I haven't for my test server), the subdirectory modules doesn't exist, so mod_perl.so is put into the apache2 tree as _file_ 'modules' under /usr/local/apache2. That's why I couldn't find it! [...] This is a known problem. I came up with this patch: http://marc.theaimsgroup.com/?l=apache-modperl-devm=103847596809386w=2 But I'm afraid it's not portable and hence I couldn't commit it. Here is the relevant snippet of the patch: install: + test -d $(MODPERL_AP_LIBEXECDIR) || mkdir $(MODPERL_AP_LIBEXECDIR) $(MODPERL_TEST_F) $(MODPERL_LIB_DSO) \ $(MODPERL_CP) $(MODPERL_LIB_DSO) $(MODPERL_AP_LIBEXECDIR) Any portability gurus know how to make this Makefile's line (the one with +) portable? I think 'mkdir' is portable. What about 'test -d'? __ 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: Perl Cookbook modperl chapter
Paul Lindner wrote: Hi, I only speak for myself, but I am happy to see mod_perl covered in the Perl Cookbook. Why you ask? I see the inclusion of mod_perl helping increase the size of the mod_perl pie. A rising tide lifts all boats. I second that. And just like Paul, I only speak for myself. We need more coverage/crossreference for mod_perl in places where people don't know/use mod_perl yet. If Nat's chapter gives plenty of crossreferences to the eagle book, cookbook and our new book, it's a goodness. I'd like to think of Nat's chapter as a teaser, to get the reader all excited about mod_perl. So you should a simple auth recipe and say, to learn about more complex implementation, see Chapter XXX Book YYY. Now if that reader is not really interested in getting to know mod_perl, chances are that he would never have bought Book YYY. But if Nat's chapter raised enough curiosity for that person to go and buy Book YYY, that's a goodness! Also please don't forget that the majority of mod_perl users use or at least start with *only* Apache::Registry and Apache::PerlRun, so just covering these two meaning to bring many more converts to mod_perl, by just letting them know that it takes a few minutes to make your perl/cgi scripts fly. Do they need more than that? Time will show. To me what's important is to have as many people as possible *know* about mod_perl and its strengths (and weaknesses I guess ;). Because if people don't know about mod_perl they obviously won't buy mod_perl books. The real problem with mod_perl books not selling as well as they could is the availability of the online documentation, which certainly doesn't cover the cool things in the cookbook and the eagle books, but is good enough for many purposes. So I was thinking to help the sales of our book when it hits the shelves in March 2003, we should pull the documentation site down for a few months and redirect everybody to http://modperlbook.org/ ;) (...for those who miss the smiley, I'm joking of course) __ 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: Can't find Apache::ModuleConfig
Tom Schindl wrote: Maybe one could mark the things not implemented yet with a big comment and remove things which will never implemented. I'm thinking of Apache::TIPool, Apache::ModuleConfig, ... . I'm planning to revamp these old docs all at once. Sounds good. Do you know how long this will take? Hopefully, soonish. May I ask more question? 1) How can I read params sent via GET or POST? In mod_perl-1.2x this was done via $r-param(bla). Apache::RequestRec does not provide such an method. For now use CGI.pm, till Apache::Request gets ported to 2.0. Apache::compat also provides methods to retrieve the params couldn't I use them? Sure you can. That's why there were added. Although they're a little bit buggy (see my posting from yesterday Problems with Apache::compat and german special chars ). Yes, thanks. I didn't have a chance to look at it yet. __ 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: Can't find Apache::ModuleConfig
Tom Schindl wrote: Hi, I've installed perl-5.8.0, Apache2.0.43 and mod_perl-1.99_07. Now I want to use Apache::ModuleConfig but I can't find it anywhere. I've installed everything like it was shown on perl.apache.org. What have I done wrong? Any ideas? When looking at my old perl-5.6.1 installation with apache-1.3.x and mod_perl-1.2x, I found the module. Where has it gone now, do I have to use another module instead? mod_perl 2.0 has a much improved configuration customization framework. You implement everything in perl now. There is no more Apache::ModuleConfig, but there is Apache::Module. Since the change is very significant, I don't think we will be able to provide a back compatibility layer for this one. I'm working on the documentation for the custom configuration, but I still didn't finish in as I encountered bugs, which aren't resolved yet. So, either wait a bit, till I finish the doc. Or if you are in hurry, look at t/response/TestDirective/perlloadmodule* for examples. __ 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: 0x444ba45b in prof_mark () from /usr/lib/perl5/5.6.1/i686-linux/auto/Devel/DProf/DProf.so
Ged Haywood wrote: [...] Try upgrading to Perl 5.7.2 at least. It worked for me. There are those who would recommend 5.8.0 minimum, but I'm not one. (Yet:). Eh? 5.8.0 is almost the same as 5.7.2, with mucho bugs fixed. I don't understand why do you suggest to install an unstable developers version, when there is a stable and better version out there. Whether you are running 5.7.2 or 5.8.0, do not compile with ithreads support, unless you need it, as it makes the interpreter slower. __ 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: [mp2] Warnings not showing in Apache log?
Andrzej Jan Taramina wrote: Later on you have reported that some problems went away. Does it include this one? I'm now seeing warningsbut they are flagged as [error] instead of [warning] in the Apache log. Any idea why? Does this happen when you run 'make test' as well? e.g. when you run: t/TEST -v api/aplog (see the corresponding t/response/TestAPI/aplog.pm) And when running under mp2, the lines in the log are not written using cr/lf on my windoze server like they should be. only lf (\n)? Unfortunately, I live in the country and my access is dial through Bell Sympatico...which is Bell Nexxia. Seems that your mail server bounces anything coming in from my ISP. Probably they are on the RBL. Not much I can do about that though, hence this response was posted to the list ;-( Hehe, your server bounces my emails as well ;) But that's a good thing for once, as this thread shouldn't leave the list. __ 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: All tests fail with Apache/2.0.43 (Unix) mod_perl/1.99_07-dev
Richard Curtis wrote: OK, after following the instructions requested by Stas Bekman, it still doesnt work... Below is a list of everything I have type. I dont claim to be a major expert or anything, so I have included all the commands in full to help catch if I missed something :) [...] I still can't reproduce this. Though your error_log shows a different problem. after adding PerlOptions +Autoload to make the httpd.conf read as follows : IfModule !mod_perl.c PerlOptions +Autoload LoadModule perl_module /home/richard/modperl-2.0/src/modules/perl/mod_perl.so /IfModule PerlOptions should come *after* you load LoadModule [...] __ 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: 0x444ba45b in prof_mark () from /usr/lib/perl5/5.6.1/i686-linux/auto/Devel/DProf/DProf.so
Ged Haywood wrote: Hi Stas, On Sun, 8 Dec 2002, Stas Bekman wrote: Ged Haywood wrote: [...] Try upgrading to Perl 5.7.2 at least. It worked for me. There are those who would recommend 5.8.0 minimum, but I'm not one. (Yet:). Eh? 5.8.0 is almost the same as 5.7.2, with mucho bugs fixed. I don't understand why do you suggest to install an unstable developers version, when there is a stable and better version out there. Simply that I've never upgraded to 5.8.0 myself and I've seen a few people with some troubles when they did. I've had no trouble at all with 5.7.2. If there are any troubles, they should be reported to p5p. Personally I didn't have any. Mandrake 8.0 uses 5.8.0 for its all tools and it works, so does the new RH. You may remember I had segfault problems with dprof and 5.7.1 which went away when I upgraded to 5.7.2 (it was you who suggested it:). At that time there was no 5.8.0 available. I see no reason why we should mislead readers, saying do not upgrade to 5.8.0, but to 5.7.2 instead. __ 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: [mp2]Kow do I find dovumention on...
There are many methods in 2.0, most directly glued from apache and apr methods. We want to re-use their docs as is, where possible. Meaning that we need a tool to extract these. Lyle and Gerald are working on this tool, please help them to get it out asap. See the threads on the docs-dev list: http://mathforum.org/epigone/modperl-docs-dev/fyhahmen http://mathforum.org/epigone/modperl-docs-dev/sayyarsnin Currently, your best friend to finding out what 2.0 is capable of doing is to grep/browse test handlers in t/, since most of the API is covered and exercised by these tests. __ 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: Can't find Apache::ModuleConfig
Tom Schindl wrote: Thanks Stas. The documentation on perl.apache.org pointed me in a wrong direction (e.g. Apache::DBIPool (http://perl.apache.org/docs/2.0/user/overview/overview.html#Apache__DBIPool)) --cut- use strict; use Apache::TIPool (); use Apache::ModuleConfig (); use DBI (); --cut- Maybe one could mark the things not implemented yet with a big comment and remove things which will never implemented. I'm thinking of Apache::TIPool, Apache::ModuleConfig, ... . I'm planning to revamp these old docs all at once. May I ask more question? 1) How can I read params sent via GET or POST? In mod_perl-1.2x this was done via $r-param(bla). Apache::RequestRec does not provide such an method. For now use CGI.pm, till Apache::Request gets ported to 2.0. 2) Will Apache::TIPool ever implemented? Not in the way it's described in the overview, but yes should be implemented at some point. __ 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: mod_perl + mod_rewrite
P. Zadikian wrote: Hello, Is there some way to set mod_rewrite rules in a Perl/Perl section in the apache configuration? Just like any other httpd configuration, as explained here: http://perl.apache.org/docs/1.0/guide/config.html#Apache_Configuration_in_Perl and in much more detail in the eagle and the cookbook. You can even write your own PerlTransHandler which will do the rewrite... __ 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: [mp2]: Problem running scripts with Apache::compat and PerlRun.
Bill Drury wrote: -8-- Start Bug Report 8-- 1. Problem Description: I've been getting a consistent error attempting to run scripts with PerlRun and the Apache::compat layer. It may just be a configuration error, but I'd appreciate anything you could tell me. Use ModPerl::PerlRun instead of Apache::PerlRun. The former is a special version written for 2.0. __ 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: apache2 + mod_perl2 + dbd::oracle
Fabian Kreitner wrote:
[...]
$ENV{'ORACLE_HOME'} is set correctly right before the connection attempt
(it missing would result in an additional warning in the trace). Also,
the same script run from bash does successfully connect (same users, all
envs set in script).
read the info at the link I've posted in the prev reply. it doesn't work
this way anymore. explanations are there.
I did an additional installation with apache-1.3.27 mod_perl-1 and in
this combination the test script does work =/
--
__
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::Hook
Yuriy Syrota wrote: Hello, folks. Could anybody explain me how can I specify apache hooks in the module? In the other words, I want to do exactly what described here: http://perl.apache.org/~dougm/modperl_2.0.html#new%20hook%20scheme Although it's unclear for me what I should use() to use Apache::Hook. It's not (fully) implemented yet. Patches are welcome. That doc is a bit dated and certaint things have changed. Please refer to the mostly up to date docs at perl.apache.org. There are two docs that are outdated a bit there and require cleanup: http://perl.apache.org/docs/2.0/user/overview/overview.html http://perl.apache.org/docs/2.0/user/design/design.html so I suggest to not look at them at this time, as the material in them is mostly covered in the rest of the 2.0 docs. That reminds me that I need to add the 'what's new chapter from my tutorial. will do that shortly. p.s. Yuriy, I'm working on the custom conf directives doc now and hopefully should be done soon, so you can get going with the axkit porting. __ 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: [mp2] LogHandler configuration problems
Beau E. Cox wrote: Hi Stas - ...look at the error log... For the first test, which my logger reported: ::1 [Wed Dec 4 19:58:13 2002] / 404 266 ::1 [Wed Dec 4 19:58:24 2002] /index.html 403 280 ::1 [Wed Dec 4 19:58:45 2002] /perl/rocks.html 200 29 The error log reported: [Wed Dec 04 19:58:13 2002] [error] [client ::1] Attempt to serve directory: /srv/www/htdocs/ [Wed Dec 04 19:58:24 2002] [error] file permissions deny server execution/srv/www/htdocs/index.html I don't see that these error_log entries ...revealed the problem right away, from the first test... To me, newbie that I am, they give abount the same information that my logger gave... bummer ;) I was sure that registry will complain in the logs, but forgot that Apache got on its way. So you were right and I wrong ;) Glad that you've figured it out. OK, I'll relax. The secret is to read and test more before crying wolf you'd be surprised how many times i've cried wolf myself... even did that, this morning ;) __ 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: Online Tonight
David Wheeler wrote: All, I will be the featured guest for an hour on the nationally syndicated talk radio show Online Tonight this evening at 8 pm PST (11 pm EST). Host David Lawrence and I be discussing Bricolage, its history, and content management in general. This is my first time on the radio, so it should be interesting. The show is a light, humor-oriented tech talk show, and is, along with Online Today, the most listened to high-tech-oriented talk show on the air today, according to CNET Radio. The show's web site: http://www.online-tonight.com/ To listen in via streaming media: http://www.cnet.com/broadband/0-7227152.html Hi David, Care to share with us how was the show? And how much mod_perl talk was in it? Unfortunately I wasn't able to listen to the broadcast due to some sw issues, the browser just hanged there... If the show was of interest to other mod_perl users, is there an mp3 that we can link to from perl.apache.org? __ 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: apache2 + mod_perl2 + dbd::oracle
Marcin Kasperski wrote: Fabian Kreitner [EMAIL PROTECTED] writes: Hello all, I have problems connecting to an oracle db using mod_perl but cant figure out where the problem is. The script works fine from the bash but not through perl::registry. The script only sets the environment variables and then tries a connect. (...) !! ERROR: 12154 'Error while trying to retrieve text for error ORA-12154 (DBD ERROR: OCIServerAttach)' Either you removed message files from your Oracle installation (not very likely) or you failed to set ORACLE_HOME so that OCI libraries below DBD::Oracle notice this variable. Double check the way you set your environment. And if that's the case, watch the new culprit under 2.0: http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html#C_Libraries_Don_t_See_C__ENV__Entries_Set_by_Perl_Code __ 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: Online Tonight
David Wheeler wrote: On Thursday, December 5, 2002, at 12:46 AM, Stas Bekman wrote: Care to share with us how was the show? And how much mod_perl talk was in it? I certainly mentioned how important Perl, mod_perl, Apache, Mason, and PostgreSQL are to the success of the project. The show went pretty well (and a few people who listened agree), but I think I got only around 10-12 minutes time talking in the whole hour! Such is the nature of commercial radio, I guess. They plan to have me on again, though -- perhaps live from the floor of Macworld Expo; we'll see. I'll certainly keep pumping the above-mentioned software, though -- it's all crucial! Great! Unfortunately I wasn't able to listen to the broadcast due to some sw issues, the browser just hanged there... If the show was of interest to other mod_perl users, is there an mp3 that we can link to from perl.apache.org? The show is online here: http://www.onlinetonight.net/archives/001100.html I was on in the second hour (photo to appear later today), and you can listen to it via a WMA file. They were kind enough to give me MP3s of the hour, and once I get them edited, I'll post them somewhere. Probably on bricolage.cc. I think it might be of interest to others, although I suspect that the edited version might be of most interest, once I can provide it. When you get the mp3, please send us a link, so we can link to it from perl.apache.org! 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
Re: [mp2]Cookies?
Beau E. Cox wrote: Hi Randy - Sorry, I should have been more explicit. I am trying to use Apache::Cookie. AFAIK, Apache::Cookie won't work under mp2, because Apache::Request wasn't ported yet. Trying using CGI::Cookie for now, as it has the same API and implemented in pure perl. Notice that this is not an issue of Apache::compat, because Apache::Cookie is implemented in XS. What's with the Apache/test.pm (small 't')? I added use Apache2; (to add apache2 stuff to the @INC) - same results with or without it. Searched for Apache/_small t _est.pm - not found. That's an older testing package coming from mp1. It won't work with mp2. __ 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: Mod Perl in Linux Mandrake
Carlos Kassab wrote: Hi: I installed Apache in Linux Mandrake, Mod perl seems to be installed according the rpm. Now i installed the ASP module but i get the message that the Module Apache:: ASP does not exist. Somebody would knows how to solve this? Thank you in advance for your help Do yourself a favor and build everything by yourself. When you do that, you don't need to guess why this or that doesn't seem to be what it's likely to be. ... If you persist and want to use a prepackaged things, that's cool too, but... you have to be more helpful if you want help: What Apache version do you have installed? What mod_perl version you *seem* to have installed? Can you use mod_perl as it's installed? What perl version do you have installed? When you've installed Apache::ASP (I assume via CPAN.pm) which Perl installation did it go to? Was mod_perl compiled with the same Perl, you've installed Apache::ASP with? There are so many different versions and flavors of everything. If you don't tell us *all* the details, we can't guess what you have. __ 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: [mp2] default values for PerlInterp directives?
Andrzej Jan Taramina wrote:
Does anyone know what the default values are (that is, if you don't specify
them) for the PerlInterpX directives? I can't find this info anywhere in the
docs...
PerlInterpStart
PerlInterpMax
PerlInterpMinSpare
PerlInterpMaxSpare
PerlInterpMaxRequests
PerlInterpScope
Thanks!
from scr/modules/perl/modperl_config.c:
void *modperl_config_srv_create(apr_pool_t *p, server_rec *s)
{
[...]
scfg-interp_scope = MP_INTERP_SCOPE_REQUEST;
/* XXX: determine reasonable defaults */
scfg-interp_pool_cfg-start = 3;
scfg-interp_pool_cfg-max_spare = 3;
scfg-interp_pool_cfg-min_spare = 3;
scfg-interp_pool_cfg-max = 5;
scfg-interp_pool_cfg-max_requests = 2000;
[...]
they aren't documented because it wasn't decide what the default should
be. But you are right, I'll document the current defaults and we will
adjust the documentation if there are any changes.
__
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: [mp2] Documentation/LogHandler question
Beau E. Cox wrote: Hi - In: http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlLogHandler, the PerlLogHandler documentation, the configuration file sample setup is given as: Location /users/ SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlLogHandler MyApache::LogPerUser Options +ExecCGI /Location Now I wrote a simple log handler and had no end of problems (will detail upon request) with this configuration. Please do so. Since I want to intercept _every_ access to my server, I ended up with: Location / PerlLogHandler MyApache::Logger /Location and then shortened it to: PerlLogHandler MyApache::Logger where MyApache::Logger is the name of my logging perl script. I works perfectly. Do you really need all the other 'stuff'? Since this is a log handler why would you need the ResponseHandler, etc.? Of course you don't need it. I've added it so the example will be complete (i.e. you need some kind of response handler, or I guess you could rely on the default handler) As you have gathered, this is my very first mod_perl handler :) You probably want to get hold of the eagle and the RW mod_perl books. Though covering mod_perl 1.0, most of the information you learn applies to 2.0 as well. Think of 2.0 as 1.0 on mushrooms. For the books info see: http://perl.apache.org/docs/offsite/books.html#Learn_mod_perl PS: Hey Mr. 100%, mod_perl 2.0 rocks! ;) p.s. Geoff, we need a short acronym for your book so it's easy to refer to it, (a new eagle), I've called it RW (RedWhite), if you have a better idea, please suggest. __ 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: DSO/Tru64 (was Re: References for modperl usage in financialinstitutions?)
Marcin Kasperski wrote: PS If only someone had some idea how to solve the DSO/Tru64 problem... We really need to find people on these platforms (True64, AIX, HP-UX, etc.) who can help to reproduce and resolve this kind of probs. If you know of those willing to help please ask them to subscribe on this list. I am using Tru64 - and if you have any suggestions of what to try, I will do it... I wish it was that simple :( You really have to know the peculiarities of the system to know why the behavior is different. -- __ 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: [mp2] LogHandler configuration problems
Beau E. Cox wrote: Well Stas, you asked for it... :) [...] #---mod_perl 2.0 rocks test- Alias /perl/ /srv/www/conf/perl/ Location /perl/ SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI /Location #---MyApache-FileLogger- Location / SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlLogHandler MyApache::FileLogger Options +ExecCGI /Location As you have figured out by trial and error, if you wanted the logger to work for everything you just needed to add: Location / PerlLogHandler MyApache::FileLogger /Location what you originally did, is assigned ModPerl::Registry to serve everything on the server, but fed it with html and images, forgetting that it requires a Perl diet. Since you've repeated many times that you are a newbie, I'll forgive you ;) But if you weren't a newbie and you didn't remember to check the error_log file, I'd say: shame on you :) As the latter would have revealed the problem right away, from the first test. Notice that my example configuration is correct since it demonstrates the use of a logger for a particular sub-section of the site that *happens* to be served by the ModPerl::Registry handler. Perhaps that example needs some extra notes to avoid this kind of confusion in the future. I'll add a note. __ 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: Horrible handler memory leak
Hann, Brian wrote: I'm having a problem with a fairly simple handler eating up resources and I'm wondering if there's any easy way to track it down. The handler fetches data from an Oracle database and displays it using Template-Toolkit. Nothing fancy, just some display logic, etc. The thing is, when I try to show all 8000 records the process spirals upwards towards 500M and it has to be killed. With smaller amounts of records (~100-1000), the process STILL grows by several megs. There really isn't that much data going through other than the sheer amount of records so I'm wondering what's eating the resources. When storing lots of small records in Perl the overhead of the data management is very big. You can check the real memory usage with B::Size (which can be conveniently invoked via Apache::Status). See http://perl.apache.org/ for some examples. Consider using some other way to represent data in your perl code (e.g. dbm files). Also see the list archives for similar discussions. __ 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: [mp2.0]make test problems
There are two problems: C. Apache/Const not found: Can't locate Apache/Const.pm in @INC (@INC contains: Apache-Test/lib /usr/local/addons/mod_perl-1.99_07/Apache-Test/lib /usr/local/addons/mod_perl-1.99_07/lib /usr/local/addons/mod_perl-1.99_07/blib/lib /usr/local/addons/mod_perl-1.99_07/blib/arch /usr/local/addons/mod_perl-1.99_07/t/../Apache-Test/lib /usr/local/addons/mod_perl-1.99_07/t/../lib /usr/local/addons/mod_perl-1.99_07/t/../../lib /usr/lib/perl5/5.8.0/i586-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl .) at /usr/local/addons/mod_perl-1.99_07/t/response/TestApache/subprocess.pm line 12. BEGIN failed--compilation aborted at /usr/local/addons/mod_perl-1.99_07/t/response/TestApache/subprocess.pm line 12. Here is where Const.pm (actually several vertsions of them) is in the mod_perl tree (looks like the @INC should have a --/Apache2/Apache-- in it) (all below are from /usr/local/addons/mod_perl-1.99_07/): blib/lib/Apache2/APR: -r--r--r--1 root root 160 Apr 11 2001 Const.pm blib/lib/Apache2/Apache: -r--r--r--1 root root 324 Aug 28 16:28 Const.pm blib/lib/Apache2/ModPerl: -r--r--r--1 root root 743 Sep 5 07:07 Const.pm xs/APR/Const: -rw-r--r--1 beau mysql 160 Apr 11 2001 Const.pm xs/Apache/Const: -rw-r--r--1 beau mysql 324 Aug 28 16:28 Const.pm xs/ModPerl/Const: -rw-r--r--1 beau mysql 743 Sep 5 07:07 Const.pm It wants /usr/local/addons/mod_perl-1.99_07/blib/lib/Apache2/Apache/Const.pm but for some reason blib/lib/Apache2 is not in the path. modperl_extra.pl loads Apache2, so @INC should be adjusted. What happens if you run this test standalone, like so: t/TEST apache/subprocess even better in a verbose mode: t/TEST -v apache/subprocess (watch the error_log) The second problem manifestates in the error_log file: [Mon Dec 02 05:08:38 2002] [error] [client 127.0.0.1] mkdir /usr/local/addons/mod_perl-1.99_07/t/htdocs/perlio: Permission denied at /usr/local/addons/mod_perl-1.99_07/Apache-Test/lib/Apache/TestUtil.pm line 128 it tries to create a new dir 'perlio' in the dir 'htdocs' and fails. Apparently your umask is set to some value that when untarring the package the writable bits weren't set. What does the following show? cd /usr/local/addons/mod_perl-1.99_07/ ls -dl t/htdocs You are not the first to report this problem. I suppose we should add some code to check that t/htdocs is writable. BTW, when you have tests failing, run them separately and then you will immediately what errors are relevant for this test. You can even tell it to run/skip specific subtests... MaxClients (in t/conf/httpd.conf): ... IfModule worker.c StartServers 1 MaxClients 1 MinSpareThreads 1 ... Tried setting it to 150 before make test, but he sets it back to 1! if you read the head of that file, it's autogenerated and all your changes will be overwritten. If you really want to change it (and most likely you don't, since some test rely on the fact that there is only one process/thread that responds, read the Apache::Test guide here: http://perl.apache.org/docs/general/testing/testing.html#Starting_Multiple_Servers G. I hope you folks don't think I'm just dumping this on you; I have tried everthing I could think of before reporting; I'm really trying to RTFM and learn while I'm doing... You are doing the right thing. Your last report was very comprehensive, now we need to figure out why your system behaves differently than mine :) And you are doing a great service of shaking all those problems out for the many users to come. (hint, hint... :) __ 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: [mp2.0]make test problems
Also, can you please try to do the testing with the cvs version of mod_perl 2.0? Since chances are that some things were fixed since last release (and possibly new bugs added :) See: http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution (though use only the mod_perl cvs, not the httpd) __ 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: [MP2] Handler feauters in a filter?
Issac Goldstand wrote: I'm writing a filter in which two lines of data are to be appended to the content going back. However, I'd like to test for a 404, and if found set the response to 200. Can this be done from the output filters? Or am I going to have to do something more complex with a handler? Haven't tried this yet, but you can either write a connection filter which rewrites the headers if they were sent already, or insert your filter just before the one that generates the headers. Since you want to add something to the end, the former case is probably the best. I suggest that you ask for the best way at the httpd-dev list, as it's a pretty generic httpd topic and that list has real filter experts. Then once you figure out from them what's the best way to go (and share with us :) implementing it in perl is a piece of cake. The big problem is mod_proxy (or any other module, for that matter) - it's not as simple as checking the file on disk - the content could be coming from a proxy or from another content-handler. Any ideas? Issac -- __ 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: [mp2.0]make test problems
My ignorance is showing (20 yrs+ with M$ systems, only 1 1/2 yrs with Linux) but I did notice that mod_perl untared to beau:mysql? Where did that come from? umask? man umask only gives me (2) - programmers reference. Is there some setup parameter I should set? I've read my SuSE admin guide and can't find anything revelent. Please point me somewhere... :) No need for excuses :) as you saw in my followup it wasn't a umask issue. (Though 'perldoc -f umask' has a good explanation of umask.) Of course, I'm doing everthing logged in as root (it's my network after all, and if you can't be King of your own network...) I've never seen tar carry owner:group + perms thru an untar...they usually come out the other end root:root. Been there, done that. But now I work under my own user and rarely need to run 'su'. But that discussion belongs to a different list... We are probably going to change Apache::Test to not let you run the test suite as root (the real problem is that Apache 2.0 will refuse to start if httpd.conf file says: User root), instead of trying to guess your 'other' username. As you can see this help causes more troubles than it helps. It's some of your magic, isn't it Stas? If it has anything to do with magic always remember to s/Stas/Doug/gi __ 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: [mp2] the make test problem saga continues...
C. same Apache/Const.pm not found:
Can't locate Apache/Const.pm in @INC (@INC contains:
[...]
D. same tests failed:
apache/subprocessFAILED tests 1-4
Failed 4/4 tests, 0.00% okay
OK, here is the patch that will 100% :) fix these two problems (apply
manually or just use the cvs version):
Index: Apache-Test/lib/Apache/TestConfigPerl.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigPerl.pm,v
retrieving revision 1.53
diff -u -r1.53 TestConfigPerl.pm
--- Apache-Test/lib/Apache/TestConfigPerl.pm1 Jul 2002 07:57:15
- 1.53
+++ Apache-Test/lib/Apache/TestConfigPerl.pm3 Dec 2002 15:27:17 -
@@ -282,6 +282,13 @@
sub configure_pm_tests {
my $self = shift;
+# since server wasn't started yet, the modules in blib under
+# Apache2 can't be seen. So we must load Apache2.pm, without which
+# run_apache_test_config might fail to require modules
+if ($mod_perl::VERSION 1.99) {
+require Apache2;
+}
+
for my $subdir (qw(Response Protocol Hooks Filter)) {
my $dir = catfile $self-{vars}-{t_dir}, lc $subdir;
next unless -d $dir;
--
I hope that now you get a clean make test.
__
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: [MP2] Handler feauters in a filter?
Issac Goldstand wrote:
Implemented it in C:
if (f-r-status==HTTP_NOT_FOUND) // If this is so, we need to revamp the
request_rec
{
f-r-status=HTTP_OK; // Spoof HTTP_OK
f-r-status_line=200 OK;
APR_BRIGADE_INSERT_TAIL(ctx-bb,apr_bucket_eos_create(f-c-bucket_alloc));
// Add an EOS to the new bb
ap_pass_brigade(f-next,ctx-bb); // and pass the new bb to the next
filter
return APR_SUCCESS;
}
Not sure how to translate that to mod_perl's API (the first half is easy and
understandable in C, I think, though...)
It works exactly the same, just add $ before 'f' :) Though you don't say
where in the filter chain do you insert it and how do you configure it
(i.e. what filter type).
This was *my* solution - I'm not sure if it's the best way to do it...
I'm sure that as I delve deeper into Apache 2, I'll find better solutions...
Hence my suggestion to ask at the httpd-dev list.
__
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: [mp2.0] How do I port modules using Apache::SIG?
Clare, Bruce W wrote:
I'm attempting to run Scoop 0.9 (scoop.kuro5hin.org) under Apache2/mod_perl
2.0 running on Windows 2000, but the application was written for Apache/mp
1.x, so it uses Apache::SIG (and possibly other) modules that are no longer
in mod_perl.
The mod_perl developer documentation for porting from 1.x to 2.x doesn't
really cover the missing modules, other than to say you can use
Apache::compat to allow use of deprecated methods. This doesn't do the job
here, which makes sense because the SIG module isn't even installed on my
system. Is there any resource that discusses the changes between mod_perl
1.x and 2.x in more detail than the current developer document? The key
point here is what has been deprecated/removed/rearchitected in mod_perl
2.x? and how do I replace it?
The changes are documented here:
http://perl.apache.org/docs/2.0/user/compat/compat.html
I haven't put it into the developer's guide, but the user's guide.
Because the user's guide is for all people who write mod_perl code. The
developer's guide is for those who tinker with the core. I'll put an
xref to the above doc to avoid this problem in the fuure.
Apache::compat is certainly incomplete, as you have just figured out,
and that doc is synced with Apache::compat. But we are getting there.
Please keep reporting those missing things.
I'm not sure if mod_perl 2.0 will ever need this module (especially with
perl 5.8.0 which has safe signals). So here is a stub that let's your
1.0 code run as is. It'll be in CVS soonish.
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.71
diff -u -r1.71 compat.pm
--- lib/Apache/compat.pm23 Nov 2002 22:35:06 - 1.71
+++ lib/Apache/compat.pm4 Dec 2002 02:23:01 -
@@ -509,5 +509,14 @@
APR::Table::make($r-pool, $nelts);
}
+package Apache::SIG;
+
+use Apache::Const -compile = 'DECLINED';
+
+sub handler {
+# don't set the SIGPIPE
+return Apache::DECLINED;
+}
+
1;
__END__
__
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: [mp2.0] How do I port modules using Apache::SIG?
The changes are documented here: http://perl.apache.org/docs/2.0/user/compat/compat.html I haven't put it into the developer's guide, but the user's guide. Because the user's guide is for all people who write mod_perl code. The developer's guide is for those who tinker with the core. I'll put an xref to the above doc to avoid this problem in the fuure. While adding the xrefs I've realized that what I've said is not strictly correct, as http://perl.apache.org/docs/2.0/devel/porting/porting.html includes useful notes for code writers as well. In any case I've added xrefs to each other, so there shouldn't be a problem to find all the relevant info now. The online docs will be updated by the cron within 6 hours. __ 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: [RFC] Apache::LDAP
James G Smith wrote: Per Einar Ellefsen [EMAIL PROTECTED] wrote: Hi James, At 02:32 02.12.2002, James G Smith wrote: ( Actually, the name is chosen to `rhyme' with Apache::DBI. There are no dependencies on Apache or mod_perl. ) If there is no link with Apache::DBI, I suggest that you choose a more appropriate namespace, like Persistent::LDAP Unfortunately, that's already taken. The module on CPAN implements persistent objects with an LDAP backend (if I read the docs right). Net::LDAP::Persistent is not taken and seems like a good choice to me. --- re: modules discussion lists. Are you sure you are talking about the right list? I thought that module-authors at perl.org is the one for discussing general perl modules. Whereas modules at perl.org is for CPAN namespace registration submission. I've found the latter to be much more helpful, with Tim Bunce usually taking the pains of proposing better namespaces. So whenever I propose a new module I go first to module-authors and if nothing happens I take it to modules, which happens in any case, because I want my modules to be registered. p.s. those module authors who want their modules to be registered (it's not enough to upload the module on CPAN), login into your PAUSE account and go to the registration section. If you have further questions module-authors at perl.org is the place to ask them. __ 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: Install problem...
Beau E. Cox wrote: Hi - I am trying to upgrade my test server (SuSE 8.1) to Apache/ mod_perl 2. I installed and tested Apache 2 - all OK. Beau, when reporting problems, please follow the guidelines linked from the perl.apache.org's shortcuts menu: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems I have perl 5.8.0 (pre-build by SuSE); It passed the tests in the mpd_perl 2 prequsites section. I get this problem on make test (both with Apache mpm configured as prefork AND worker): apache/subprocess1..4 # testing : passing ARGV # expected: [ # 'foo', # 'bar' # ] # received: [] not ok 1 # testing : passing env via subprocess_env # expected: 'my cool proc' # received: '' not ok 2 # testing : testing subproc's stdin - stdout + list context # expected: 'my cool proc # ' # received: '' not ok 3 # testing : testing subproc's stdin - stderr + list context # expected: 'my stderr # ' # received: '' not ok 4 FAILED tests 1-4 Failed 4/4 tests, 0.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- apache/subprocess.t44 100.00% 1-4 I haven't got a clue. This is my sixth reRTFM/reinstall/retest. Could someone give me a push as to what to try next? I forgot to add to the guidelines to check t/logs/error_log, will add it now. So what does your error_log say? Most likely some perms problems with t/htdocs/util, right? __ 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: [mp2.0]make test problems
That's much better! -8-- Start Bug Report 8-- 1. Problem Description: MP make test fails (no error log generated) A. Apache/Const.pm not found - snip of console output: [START] *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -clean *** setting ulimit to allow core files ulimit -c unlimited; t/TEST Can't locate Apache/Const.pm in @INC (@INC contains: Apache-Test/lib [...etc...] You've snipped it in the bad place. What's the reported @INC? But first try with the last suggestion in this reply. I looked on CPAN but Apache::Constants seems to be part of MP1. B. 'test mode' apache doesn't start (it starts OK using apachectl start): Syntax error on line 27 of /usr/local/addons/mod_perl-1.99_07/t/conf/httpd.conf: Invalid command 'TransferLog', perhaps mis-spelled or defined by a module not included inthe server configuration !!! server has died with status 255 (t/logs/error_log wasn't created, start the server in the debug mode) make: *** [run_tests] Error 143 line 27 ot the test httpd.conf file: 26: LogLeveldebug 27: TransferLog /usr/local/addons/mod_perl-1.99_07/t/logs/access_log 28: 29: ServerAdmin nobody@localhost You miss mod_log_config.c, see the next answer C. NOTE! I have gone backwards! My previous incarnations of mod_perl install have gotten further than this. My change - configured Apache with 'all' modules: ./configure --enable-layout=SuSE --enable-mods-shared=all --with-mpm=worker please try first with just: ./configure --with-mpm=worker as suggested by the docs. __ 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: [mp1] Still can not get working DSO configuration on Tru64
Marcin Kasperski wrote: In short: I tried different compilation methods with two possible outcomes: a) apache and modperl compile succesfully but I get coredump while the application is starting (in all cases SEGVs, in some cases core's confused the debugger, in other I managed to notice __at_fork in backtrace) b) everything seem to compile succesfully but I get dlopen: /tools/apache/libexec/mod_perl.so: symbol PL_perl_destruct_level unresolved while the application is starting Maybe it is worth noting, that I happened to get b) also when I compiled perl with shared perl library (in contrary to suggestion found in modperl docs that building perl with shared library should help). 2 years ago, there was a similar struggle as you can see from this thread: http://marc.theaimsgroup.com/?t=9744223061r=1w=2 May be those participants are still using True64 and can give you some hints? __ 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 2?
3. If you have different sites (presumably owned by different people) on your server, all the backend servers can execute with different userids so that the backend server of one site doesn't have to be able to read the files of another site. And, everyone can change their own server configuration. We know that Apache 2 confers benefit #1 without needing a separate frontend and backend. Benefit #2 seems to be planned, but isn't here yet. ...What about benefit #3? #3: --with-mpm=perchild which is a work in progress http://httpd.apache.org/docs-2.0/mod/perchild.html notice the new AssignUserID and ChildPerUserID directives which now can set different uid/gid for each group of processes/threads. __ 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: default Content-Length calculation has been removed in 2.0 (wasRe: mod_perl 2.x vs. mod_perl 1.x benchmarks)
Well, it's been getting *WAY* OT - more geared for dev@httpd if anywhere, but I'm sure they've argued this out already :-) My initial ideas all counted on the fact that each handler/filter would have a way of getting its own per-request thread... On the opposite, IMHO this is very ON topic, since that's the core of the 2.0. there is a talk about async I/O mpms for 3.0, or later 2.x This sounds like our many buckets with firemen scenario - but, again, it only really becomes useful if the handlers/filters have their own thread running space. That's the real pipeline. But it'll be only useful if you have many CPUs. I remember reading somewhere, that on a single CPU sequential processing might be faster rather than pseudo-parallel, because of the context-switch overhead. Though admittedly it's much smaller with threads, but depends on the implementation. Now, nothing prevents you from developing your own mpm right now or at any time latter that will do what you want. It's actually much easier that it seems to be because a big chunk of functionality is abstacted away. So it's not like writing an Apache server from scratch. I admit that I haven't written my own mpm yet and that's the impression that I have from reading posts at httpd-dev. But the conclusion I'd draw from this, getting back to the original question, is that under Apache 2, it's *still* worth doing a frontend/backend setup where the frontend buffers all the backend data. Even if we *did* write the buffer filter, if the whole pipeline is stuck in one thread, then we're not freeing up the resources when the heavy handler/filter is done, so slow clients will still clog server resources. Yes and no. Remember that our perl interpreters live in a separate pool of threads, so if we can release them asap, they can go and serve more requests, while the filters do whatever they do. Since the perl interpreters don't reside on the same thread that serves the connection. Though you are correct that the response handler won't be released until the filters will be done. So we need to think of some trickery to release the response handler earlier. The frontend/backend solution takes care of this, because here, we're creating our own 2-threaded pipeline: the important thing being that the frontend should either have a buffer filter, or better yet, a constant flush + buffer filter to get the data from the backend straight to the client, while buffering additional data if needed. Does this make sense to you? Sure, there is nothing wrong with front/end backend setup, it just makes things a bit more complicated to setup and maintain. So if we can provide an alternative solution that requires only one server, that would be cool. That's said let's worry first to get the core things working first and if you want to play with optimizations please go ahead and hack away :) __ 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
[patch] Apache::DB now works with 5.8.0+
To all those having problems with Apache::DB and perl 5.8.0+ (CC'ing all
those who have complained recently).
Try this patch:
--- Apache-DB-0.06/DB.pm.old 1999-10-12 07:50:33.0 +0800
+++ Apache-DB-0.06/DB.pm 2002-11-29 18:03:47.0 +0800
@@ -14,6 +14,7 @@
$Apache::Registry::MarkLine = 0;
sub init {
+*DB::DB = sub {} unless DB-can(DB); # temp definition for 5.8.0+
if(init_debugger()) {
warn [notice] Apache::DB initialized in child $$\n;
}
__
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: [mp 2.0] can not compile mp 1.99_07
Dipl.-Inform. Kai Hofmann wrote: I tried to compile 1.99_07 - but there is a definition of IoTYPE_WRONLY and IoTYPE_REONLY within the file apr_perlio.c which can not be resolved unter SuSE Linux 7.2 with Apache 2.0.43 I greped all includes without any success where these things will be defined - any hints? Last time I compiles 1.99_03 successfully. Thanks for the report Kai. Fixed in the current cvs. __ 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
Fwd: Red Hat's use of mod_perl
Thanks Chip, great info! please keep those coming, we will update the site once we have several of these new additions. The original request is here: http://use.perl.org/articles/02/11/29/1837238.shtml?tid=11 Original Message Subject: Red Hat's use of mod_perl Date: 29 Nov 2002 23:30:24 -0500 From: Chip Turner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hey Stas, Just saw your request on use.perl.org. Red Hat's main website, www.redhat.com, is a mod_perl site (mainly Apache::ASP). Also, the Red Hat Network's website, rhn.redhat.com, is pure mod_perl, using a custom templating system (which I'll release one day, as soon as I find time..). It's actually a fairly complicated use of mod_perl for a web application, totalling around 60k likes of perl. Hope this is useful, Chip -- Chip Turner [EMAIL PROTECTED] Red Hat, Inc. -- __ 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 2?
Issac Goldstand wrote: - Original Message - From: Stas Bekman [EMAIL PROTECTED] . Since if your mod_perl handler sends the data to a thread which runs a filter that send the data to a client (and doesn't need perl) it'll still block on the network transfer, which will block the response handler sending the data. So I can imagine that we will need a special filter that buffers the data, immediately releasing the perl handler and then slowly feeding it to the the client. This isn't just a mod_perl thing, either. This would be a generic Apache2 thing. *ANY* content should be filtered as such through a 2-tier system like this - but I thought that's what the bucket brigades did. Please correct me if I'm wrong in this picture: Response Handler start of buckets Filter API End of buckets Core Output client it was my understanding that one of the purposes of the core-output filter was to do exactly what we want - free the backend request and filter threads once they've finished with the EOS bucket. Am I missing something? From a quick read through: server/core.c:static apr_status_t core_output_filter(ap_filter_t *f, apr_bucket_brigade *b) I don't think core_output_filter does anything to buffer up the data and release the handler. The only buffering it does is if it doesn't have *enough* bytes to send so it waits for the next brigade. In order to understand how the new model works you really have run the snooping filter and study the output. The important outcome that you gain is that filters are called in a pipeline, i.e. the response handler sends a portion of data to the first filter, which immediately passes that data to the next filter, and so on, while all previous filters that have already passed the first chunk await for the latter filters to return. That's my understanding so far, please correct me if I'm wrong. So if you want to release the handler asap, you need a filter that will buffer up the data and feed it to the remaining filters at the speed they request. It should probably be inserted just before the core_output_filter, so all the processings will be already completed by that time. Think of it as an extension to the core_output_filter which buffers things up. And the cool thing is that you can inject it only when you want it, e.g. you don't want it for non-mod_perl requests. And of course it's not mod_perl specific like you've mentioned, but I don't really know of any other producers that consume a lot of memory and therefore for which we want to minimize their number and keep them busy for real all the time. __ 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: segmentation fault using a startup file
Ged Haywood wrote: On 27 Nov 2002, Jan Theofel wrote: Especially because we use SuSE Linux Enterprise Server which is a hihgly integrated system and we would loose the benefits of this system when we compile apache on our own. I don't understand that at all. Can somebody help me out here? Sure. Many (linux|other) systems nowadays rely on Apache and Perl to do the UI to the system. Therefore they sometimes (always?) patch or change these tools to do what they want them to do. And when you want to add your own things collisions might happen. Therefore if you want to keep the system intact, build your own Apache and your own Perl in a different directory. You especially want this if you are a developer that need to make sure that the product works with various versions. e.g. I have: % ls ~/perl/ 5.005_03 5.6.0 5.6.0-ithread 5.6.1 5.6.1-ithread 5.8.0 5.8.0-ithread blead blead-ithread % ls ~/httpd/ 1.3 2.0 prefork prefork-apreq threaded worker Of course you probably don't need them all, but you get the idea. the only caveat of installing your own Apache is that you can't use port 80, if the system's Apache uses it. A simple rewrite rule solves this problem. __ 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
default Content-Length calculation has been removed in 2.0 (was Re:mod_perl 2.x vs. mod_perl 1.x benchmarks)
Frank Wiles wrote: .--[ Ask Bjoern Hansen wrote (2002/09/19 at 01:47:39) ]-- | | On Wed, 18 Sep 2002, Josh Chamas wrote: | | [...] | So I run it again with ServerTokens Min, and get the same results. :) | Still something different on the mod_perl headers, looks like mod_perl | 2.x is setting Content-Length where it didn't use to. | | The details evade me, but I recall something about how the buckets | work in the httpd that makes httpd 2.0 always know (and set) the | Content-Length. | | There was discussion about changing it; but I don't remember the | outcome. This has been changed to do the right thing around mid-Sep I believe. Previously httpd was buffering up the output and calculating the Content-Length header before sending the HTTP headers. It doesn't do that anymore, which is a relief for us. I've discovered this just before my presentation, where I've planned to demonstrate that bad behavior using the filter snooper, but there was no need any more :) You can still inject a cl filter which will buffer the data and calculate its length e.g. to be cache friendly, if that's your intention. Actually, returning to Issac's question regarding releasing the handler early, you need a slightly modified version of the cl filter to do that. Since it's already buffering the data, you just want to do this unconditionaly. __ 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: Compilation problems with mod_perl
Stas Bekman wrote: Benny Jensen wrote: Hello, I'm trying to compile mod_perl for apache2. But i got a error message that i dont know how to solve. The following message is what i get: /LD_RUN_PATH= cc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/Apache2/auto/APR/APR.so -lapr -laprutil /usr/bin/ld: cannot find -lapr collect2: ld returned 1 exit status / APR.so exist in following map: //usr/local/lib/perl/5.8.0/Apache2/auto/APR/APR.so/ If anyone could help me to solve it it's looking for libapr, not APR. You must have messed up the apache build step or missed it completely and don't have apache built yet. Review the installation steps at: http://perl.apache.org/docs/2.0/user/install/install.html#Condiguring_and_Installing_Prerequisites That was actually a broken build after the apr project has changed the way it names the libraries. So please disregard my previous reply and get the latest cvs, it should work 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
Re: PATCH Apache::Status.pm
Dan Sully wrote:
This makes the syntax tree dump work for Apache::Status
--- lib/Apache/Status.pm.orig Tue May 28 09:33:28 2002
+++ lib/Apache/Status.pm Tue Sep 24 12:09:56 2002
@@ -345,6 +345,7 @@
sub noh_b_terse {
my $r = shift;
+return unless eval { require B::Terse };
Thanks Dan. Committed this and added two more similar fixes which solve
the same problem in two other functions in that module.
__
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: flush problem
Udlei Nattis wrote:
$r-rflush() doesnt work too
you have other idea?
I believe this was a bug in httpd, where the content was buffered up to
calculate the Content-Length header. I've tested it with the cvs version
of httpd and $|=1 sends the unbuffered output as with your original example:
use strict;
$| = 1;
my ($i,$r);
$r = shift;
$r-content_type('text/html');
while ($i 10) {
$r-printf($i.br\n);
$r-printf(\0);
$i++;
sleep 1;
}
---
$r-rflush() is indeed not working yet.
__
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: default Content-Length calculation has been removed in 2.0 (wasRe: mod_perl 2.x vs. mod_perl 1.x benchmarks)
[Issac's view snipped] Rather than commenting on your view Issac, please allow me to try again to explain how I think it works, hopefully more clear this time: Let's forget for a moment about buckets inside bridades, and call the brigades themselves entities that are passed along. Now think of a realworld fireman water bucket brigade, everybody passes a bucket (entity) and usually there are several buckets (entities) moving at the same time. Now let's imagine that the first man in the brigade picks a new bucket only when the last man has poured its bucket out. So at any given moment there is only one bucket (entity) moving along the brigade. This is exactly the situation with httpd. In the current httpd filtering model one entity is moving along the filters stack and no new entity will enter the stack, before the one on the stack will leave it (go to the client if we are talking about output filters). I didn't want to use the httpd buckets and brigades in this example, because they make my comparison confusing. In the real world there is one brigade and many buckets. In httpd, there are many bridages that are moving along the stack of filters (and each brigade have one or more buckets, which are irrelevant to this particular discussion). Hope this clearifies the picture. The conclusion: If the filter stack is busy processing some data and the response handler hasn't finished sending the data, it'll block waiting for the filter stack to return and only then hand over the next chunk of data. At least that's how it appears to the filters. Now if you want to play with it, it should be a trivial thing to do. Just take some response handler that generates a lot of data in a loop and prints some logs to STDERR on each iteration, then insert a filter that passes the brigades unmodified (like MyApache::FilterSnoop does) but has a 'sleep 3' statement. I expect that the response handler will block on each sleep. I hope that my understanding was correct :) Also allow me to suggest that reading the following section: http://perl.apache.org/docs/2.0/user/handlers/filters.html#All_in_One_Filter and trying the MyApache::FilterSnoop module at work should clearify a lot. __ 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::Reload and @INC
Igor Vylusko wrote: in doc http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Reload.html declared that when using Apache::Reload I may define additional lib in httpd.conf: PerlSetEnv PERL5LIB /home/httpd/perl/extra But when I enable PerlInitHandler Apache::Reload in config all libs defined in PERL5LIB are gone away from @INC. I have Apache 1.3.27, mod_perl 1.27, Apache::Reload 0.07, perl 5.8.0 on RH7.2 and try PerlSetEnv PERL5LIB in main config section as well as in VirtualHost sections. I have bulk of VirtualHosts and would like make @INC different for each one(i.e. not use lib ... in startup.pl). SB It's not easy with mod_perl 1.0. The manpage is talking about changing SB @INC globally for the whole server. I usually do that with 'use lib' in SB startup.pl. I define PerlSetEnv PERL5LIB globaly for the whole server but PERL5LIB was stripped out from @INC anyway on enabling PerlInitHandler Apache::Reload in _any_ vhost. I am using PerlSetEnv PERL5LIB per vhost basis and it works fine for me without Apache::Reload. I can't reproduce what you see with Apache::Reload and I don't see anything in the code that mangles @INC. Though what I do see, is that if you define PERL5LIB outside a VirtualHost, it overrides any PERL5LIB defined inside all VirtualHosts, no matter if you use Apache::Reload or not. I don't remember if that's how it should be or whether it's a bug. Those who use vhosts can probably help rectify the issue here. __ 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: New problems making mod_perl run: Apache/2.0.43 (Unix) mod_perl/1.99_07-devPerl/v5.8.0
Juan Julian Merelo Guervos wrote:
Hi,
Well, looks like I've managed to make this server run (thanks for your
help), and looks like, in this case, mod_cgi is working (unlike the one
shipped with RH 8.0). Now I'm trying to make HTML::Mason work with this
configuration. I have downloaded HTML::Mason 1.15, and force-compiled
it. This one requires libapreq, which I haven't been able to compile,
since it requires Apache::MyConfig . That's supposed to be in the old
version of mod_perl, right? So, the only way to have HTML::Mason working
is to have both things working at the same time? Any other option? Has
anybody made HTML::Mason work with this prerrelease of mod_perl?
I did a quick stub on porting Apache::MyConfig, it's incomplete so
please post any fixes (which should be pretty easy to figure out) for
those keys that weren't set yet. So here is the patch.
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.71
diff -u -r1.71 compat.pm
--- lib/Apache/compat.pm 23 Nov 2002 22:35:06 - 1.71
+++ lib/Apache/compat.pm 28 Nov 2002 16:52:49 -
@@ -509,5 +509,80 @@
APR::Table::make($r-pool, $nelts);
}
+package Apache::MyConfig;
+
+use Apache::Build ();
+
+use constant WIN32 = Apache::Build::WIN32;
+
+our %Setup;
+
+my $build = Apache::Build-new();
+
+my $XXX = Need to figure out;
+my $LEGACY = '';
+
+%Setup = (
+APACHE_SRC = $build-MP_AP_PREFIX, # can be not source
+SSL_BASE = $LEGACY,
+APXS = $build-apxs,
+PERL_USELARGEFILES = $XXX, # XXX
+PERL_TRACE = $build-MP_TRACE,
+PERL_DEBUG = $build-MP_debug,
+APACI_ARGS = $LEGACY,
+APACHE_PREFIX = $build-MP_AP_PREFIX,
+DO_HTTPD = 1, # always DO_HTTPD
+NO_HTTPD = 0, # always DO_HTTPD
+PREP_HTTPD = 0, # always DO_HTTPD
+USE_APACI = 0, # no more
+APACHE_HEADER_INSTALL = 1, #
+PERL_STATIC_EXTS = $XXX,
+PERL_SSI = 0, # legacy
+USE_APXS = $XXX, # only for non-win?
+);
+
+my @callback_hooks = qw{
+PERL_DISPATCH
+PERL_CHILD_INIT
+PERL_CHILD_EXIT
+PERL_POST_READ_REQUEST
+PERL_TRANS
+PERL_HEADER_PARSER
+PERL_ACCESS
+PERL_AUTHEN PERL_AUTHZ
+PERL_TYPE
+PERL_FIXUP
+PERL_HANDLER
+PERL_LOG
+PERL_INIT
+PERL_CLEANUP
+PERL_RESTART
+PERL_STACKED_HANDLERS
+PERL_METHOD_HANDLERS
+PERL_DIRECTIVE_HANDLERS
+PERL_TABLE_API
+PERL_LOG_API
+PERL_URI_API
+PERL_UTIL_API
+PERL_FILE_API
+PERL_CONNECTION_API
+PERL_SERVER_API
+PERL_SECTIONS
+};
+
+# we have all the APIs available, just need to load their modules
+$Setup{$_} = 1 for @callback_hooks;
+
+if (WIN32) {
+$Setup{APACHE_INC} = $build-{APXS_INCLUDEDIR};
+$Setup{APACHE_LIB} = $XXX;
+$Setup{MODPERL_INC} = $build-{MODPERL_INC};
+$Setup{MODPERL_LIB} = $XXX; # win32 lib?
+}
+
+#need this alias for Apache::src backwards compat
+$Setup{Apache_Src} = $Setup{APACHE_SRC};
+
+
1;
__END__
__
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: [mp1] callback called exit (many times)
Marcin Kasperski wrote: Recently I happened to get the error log flooded with the message callback called exit (repeated a couple of million times, probably by one process or a few processes). This was some side-effect of the lack of memory (earlier in the logs I found messages about allocation failures), which in turn was caused by some non-apache process allocating too much. Nevertheless, I am trying to find what happened to my apache/modperl process (processess?). After all, aborting some processes due to lack of memory is ok, but filling the whole disk with error log is not. It is possible that the problem is not caused by the modperl itself (for instance some of additional modules we implemented in both C and perl could go wild). But trying to understand the problem I would like to ask the following questions: a) Have anyone anywhere observed similar behaviour? b) When is the message 'callback called exit' printed - and can it be disabled? c) Do you have any idea of what should I pay attention to? Hope that the following somewhat helps: http://perl.apache.org/search/swish.cgi?query=callback+called+exitsbm=SecDsubmit=search __ 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: [mp1] callback called exit (many times)
Marcin Kasperski wrote:
Stas Bekman [EMAIL PROTECTED] writes:
Marcin Kasperski wrote:
Recently I happened to get the error log flooded with the message
callback called exit
(repeated a couple of million times, probably by one process or a few
processes).
This was some side-effect of the lack of memory
(...)
Hope that the following somewhat helps:
http://perl.apache.org/search/swish.cgi?query=callback+called+exitsbm=SecDsubmit=search
Thank you for the pointer.
Am I right deducing, that I should attempt recompiling perl with
-DEMERGENCY_SBRK?
Try to, but this doesn't solve the original problem. You still have to
try to narrow down the code that causes the problem. Using ab or a
similar load tester might help to stress test.
Using tools to prevent situations when the server runs out of memory is
very important. See the online docs for more info. Using these tools
should probably solve the problem altogether, without using any special
compilation options.
The perl I use describes itself as below so probably this option is
not turned on:
Hmm, it's been a long time since we've last revisited this issue. The
doc says that PERL_EMERGENCY_SBRK it's supposed to be on, but a quick
test on several of my builds shows that it's not true:
#!/usr/bin/perl
use Inline C;
print PERL_EMERGENCY_SBRK is @{[ mytest() ? '' : 'not']} defined\n;
__END__
__C__
int mytest() {
#ifdef PERL_EMERGENCY_SBRK
return 1;
#else
return 0;
#endif
}
~/perl/5.8.0-ithread/bin/perl test.pl
PERL_EMERGENCY_SBRK is not defined
of course there is the source code, but Inline is nice :)
__
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::Reload - filtering include directories
Stas Bekman wrote: Harry Danilevsky wrote: I did send the patch to Matt couple of days ago, but haven't heard back yet. Matt is on vacation I suppose I can also brace myslef, add namespaces, and clean up my own code. That's a good idea. As for the versioning, if this patch could be useful in both mod_perl 1.* and 2.0, can it be applied to both distributions? I don't quite understand why installing Apache::Reload from CPAN will cause mod_perl2.0 to be installed, but I'll try to think some more about it. Because Apache::Reload is distributed on CPAN and is not a part of mod_perl 1.0. And a genetically modified version is included in mod_perl 2.0. The right solution is probably to make Apache::Reload a part of mod_perl 1.0 as well and kill the CPAN version, or simply have a higher number on it. So people won't need to install it manually. I've committed your patch to the Apache::Reload version distributed with mod_perl 2.0 (plus documented the new feature). I've no control over the mod_perl 1.0 version maintained by Matt. Thanks for the patch Harry. __ 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: OT: localtime can't handle epochs less than 0 ???
simran wrote: Off Topic General Perl Question --- Please don't do that. And for others, please don't reply to this kind of questions even though you know the answer, and thus encouraging these questions. Let's keep focused on mod_perl here. On another note, can anyone points me to a general perl questions list that they would recommend (not too much traffic and medium to expert level?) Certainly! http://lists.perl.org/ provides a gazillion of perl related lists and newsgroups for you choose from. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Apache::Reload and @INC
Igor Vylusko wrote: Hi All, in doc http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Reload.html declared that when using Apache::Reload I may define additional lib in httpd.conf: PerlSetEnv PERL5LIB /home/httpd/perl/extra But when I enable PerlInitHandler Apache::Reload in config all libs defined in PERL5LIB are gone away from @INC. I have Apache 1.3.27, mod_perl 1.27, Apache::Reload 0.07, perl 5.8.0 on RH7.2 and try PerlSetEnv PERL5LIB in main config section as well as in VirtualHost sections. I have bulk of VirtualHosts and would like make @INC different for each one(i.e. not use lib ... in startup.pl). It's not easy with mod_perl 1.0. The manpage is talking about changing @INC globally for the whole server. I usually do that with 'use lib' in startup.pl. Has anybody run across this problem? If sowhat is my solution? There are several solutions, none of which is very helpful in production, since they either slow things down or may cause collisions when modules with the same names are loaded, see: http://perl.apache.org/docs/1.0/guide/config.html#Is_There_a_Way_to_Modify__INC_on_a_Per_Virtual_Host_or_Per_Location_Basis_ _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: IPC::Open2, mod_perl and cvsweb
Ilya Martynov wrote: On Mon, 25 Nov 2002 23:01:44 -0500, Geoffrey Young [EMAIL PROTECTED] said: Look in archives. I think many people had problems with IPC::Open2 under mod_perl. So far the best solution I know is just replacing it with IPC::Run. Seconded. Go with IPC::Run and you won't regret, since it works under mod_perl and gives you much more than the IPC::Open* family. GY IPC::Run++ Question about IPC::Open2 under mod_perl seems to arise quite frequently. Maybe it should be added to mod_perl guide in 'Frequent mod_perl problems' section. done. will be online at the troubleshooting.html chapter on the next automatic update (within 6 hours). __ 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: Trouble with make source_scan
Esteban Fernandez Stafford wrote: Hello, I wanted to add some functionality to mod_perl. I am following the 'mod_per 2.0 Source Code Explained' guide. Before doing any change at all I tried to run 'make source_scan' and I got some errors. Going through build/source_scan.pl I was able to tell which errors where generated from each instruction (see below), but this has not brougth me any further. Can anybody give me a hint about what I could do? Thanks! mod_per: 2.0 (checked out from CVS, Nov 26 2002) perl: 5.8.0 It's not working most of the time, as Apache source gets changed all the time. You need the patched Scan.pm from apache.org/~dougm/, but it doesn't seem to work for me with the latest cvs. Hopefully Gerald Richter gets his generalized version to work asap, so we don't rely on C::Scan anymore. When the scan doesn't work, you should manually add the functions to xs/tables/current/, which is pretty easy to do if you don't have many of them. And if you have some improvements to the scarce notes in the 'mod_perl 2.0 Source Code Explained' chapter, please send me a patch... 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
Re: Problems compiling mod_perl 1.99_07 in RH 8.0
J. J. Merelo wrote: Hi, This new RH 8.0 installation is resulting in a calvary. After finding that mod_cgi does not work, that the mod_perl that comes with it breaks all scripts I've got, I have decided to build the latest apache version and mod_perl from scratch. But looks like I am also bumping into problems here: when compiling it, I get this error LD_RUN_PATH=/usr/lib gcc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/auto/APR/APR.so -L/usr/local/apache2/lib -lapr -laprutil /usr/bin/ld: cannot find -lapr Looks like that corresponds to libapreq ; but I'm not too sure where to get it. Is it included in the Apache release? Is it in apache-devel? I have found a RPM for it, but now I'm not sure that's reliable either. ¿Any idea? you have to install httpd-2.0, before you build mod_perl 2.0, and it installs apr and apr-util libs. see the online docs. __ 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: problems with characters being added to a request.
Wierd, huh? If you look in the error log, you'll see that both test1 and test2 printed out without that funny looking character. -- __ 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: Problems compiling mod_perl 1.99_07 in RH 8.0
[please, post followups to the list! everybody else on the list wants to
know the answer, not only you. thanks!]
J. J. Merelo wrote:
Hi,
Looks like that corresponds to libapreq ; but I'm not too sure where to
get it. Is it included in the Apache release? Is it in apache-devel? I
have found a RPM for it, but now I'm not sure that's reliable either.
¿Any idea?
you have to install httpd-2.0, before you build mod_perl 2.0, and it
installs apr and apr-util libs. see the online docs.
Sorry I didn't mention it, but I built apache 2.0.43 under the same
upper dir, and installed it under /usr/local/apache2. The command line
for building was:
perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2
It does have the apr and apr-util libs, in the correct directory I
guess.
ls /usr/local/apache2/lib/
apr.exp libapr-0.lalibapr-0.so.0.9.2 libaprutil-0.so
aprutil.exp libapr-0.solibaprutil-0.a libaprutil-0.so.0
libapr-0.a libapr-0.so.0 libaprutil-0.lalibaprutil-0.so.0.9.2
Do I have to define another config variable or something?
Oops, they did it again. Around mid-Sept the apr project has changed the
way they name libs. None of us have had problems because we still had
the old libs with the old conventions linked instead of the new ones.
what used to be libapr.so.0.9.2, now is named libapr-0.so.0.0.2 (same
for aprutil), similar to libdb's naming convention.
So here is the patch that will get you going if you use the current cvs.
Though it won't work with older aprs. Should probably hide the
differences in the ModPerl::MM build.
Index: xs/APR/APR/Makefile.PL
===
RCS file: /home/cvs/modperl-2.0/xs/APR/APR/Makefile.PL,v
retrieving revision 1.4
diff -u -r1.4 Makefile.PL
--- xs/APR/APR/Makefile.PL 6 Apr 2002 04:42:00 - 1.4
+++ xs/APR/APR/Makefile.PL 26 Nov 2002 13:56:11 -
@@ -4,12 +4,11 @@
my $prefix = ModPerl::MM::build_config()-apxs(-q = 'PREFIX');
-my $libdir = $prefix/lib;
-
-my @libs = map -l$_, qw(apr aprutil);
+my @libs = map { qx{$prefix/bin/$_-config --link-ld} } qw(apr apu);
+chomp @libs;
ModPerl::MM::WriteMakefile(
'NAME'= 'APR',
'VERSION_FROM' = 'APR.pm',
-'LIBS' = [-L$libdir @libs],
+'LIBS' = \@libs,
);
__
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: Identifying memory leaks
Charles wrote: A Linux machine running Apache/2.0.35 (Unix) mod_perl/1.99_05-dev Perl/v5.6.1 mysql 4.0.1 uses increasing used memory (according /usr/bin/free), eventually resuting in all memory being consumed. Memory usage drops somewhat after a reboot of apache and mysql, but not completely. Well, why it's possible. I doubt it does. Most likely your code causes the leakage. First of all, if you don't report the complete details about your build we can't even start helping to you. Use the proper procedure of reporting problem as described here: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems (linked from the shortcuts menu on the left of perl.apache.org so it's *easy* to find) Second, do you see the same behavior under mod_perl 1.0? If a reference does not go out of scope between sessions, that memory will not be garbage collected. I would like to test for these types of difficulties. First of all you should try and isolate the problem, so your test case is simple. Debugging a huge program can be a problem. The mod_perl guide discusses several ways to debug problems, though not all tools are available to 2.0 yet, so you better off debugging this with mod_perl 1.0 if possible. For example see: http://perl.apache.org/docs/1.0/guide/debug.html#How_can_I_find_out_if_a_mod_perl_code_has_a_memory_leak Questions: Are there tools to track total (all threads/processes) mod_perl, apache, mysql memory usage? Apache::VMonitor for mod_perl 1.0 should be of a good help. I've several obstacles that I'm trying to resolve at the httpd land and then I'll make it available for 2.0. What is the normal behavior for a module which connects (via a global) to a database in terms of mysql processes started? it's also possible that the way your wrote the code brings huge chunks of data from db into the memory and never frees them. (e.g. a closure problem http://perl.apache.org/docs/general/perl_reference/perl_reference.html). in summary, narrow down the test case if possible, hopefully without involving any rdbms code, send the complete details of your setup and we will see what can be done. __ 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 2?
Philip Mak wrote: On Tue, Nov 26, 2002 at 03:11:47PM -0800, Grant Cooper wrote: Is there any documention of a HOWTO or a tutorial about a lightweight front-end proxy that loads the data from the mod_perl I wrote a guide a while back on how to install mod_accel and mod_deflate with Apache. It's for Apache 1.3.x; I don't know if it will work with Apache 2.x. http://www.aaanime.net/pmak/apache/mod_accel/ and of course your perl.apache.org docs: http://perl.apache.org/docs/1.0/guide/strategy.html http://perl.apache.org/docs/1.0/guide/scenario.html __ 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 2?
Philip Mak wrote: These days, Apache 2 has become the default version of Apache. On my site, I run a front end Apache and a back end Apache. Front end: Apache 1.x, has mod_accel module which is like mod_proxy, but downloads all the data from the backend ASAP and frees it up immediately, so that a slow modem doesn't tie up the backend Back end: Apache 1.x with mod_perl Here's my question: Is it worth upgrading to Apache 2.x for either the front end or back end? And does Apache 2.x's mod_proxy free up the backend ASAP now? Theoretically with mod_perl 2.0 with Apache2.0 threaded mpms architecture the need for the front-end/back-end solution has gone away, because now you can have a few threads running Perl interpreters and many other threads which don't run Perl interpreters. So the front-end and the back-end can now co-exist on the same server. Practically we still need to work out the details. Since if your mod_perl handler sends the data to a thread which runs a filter that send the data to a client (and doesn't need perl) it'll still block on the network transfer, which will block the response handler sending the data. So I can imagine that we will need a special filter that buffers the data, immediately releasing the perl handler and then slowly feeding it to the the client. The prototype can be written in perl and then probably better ported to C. You can use the MyApache::FilterSnoop (http://perl.apache.org/docs/2.0/user/handlers/filters.html#All_in_One_Filter) to trace the data propogation through filters. Of course first you need to understand the 2.0 architecture, which is discussed in details at http://perl.apache.org/docs/2.0/user/index.html (Part IV: mod_perl Handlers). As this is a new documentation please help to improve it. Especially if you have more interesting examples, than the ones I've come up with. __ 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: partial page display
[EMAIL PROTECTED] wrote:
Thanks, finally found the right combination...
{
local $| = 1;
$r-content_type('text/html');
$r-send_http_header;
print Testing...\n;
}
Peruse the docs and they will save your time:
http://perl.apache.org/docs/1.0/guide/performance.html#Using1_Under_mod_perl_and_Better_print___Techniques_
__
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: partial page display
Jim Martinez wrote: After much thought on Nov 26 [EMAIL PROTECTED] wrote: I suspect possibly there's some massaging we can do to the header? I wonder if your thinking of the meta tag refresh : META HTTP-EQUIV=Refresh CONTENT=45;URL=http://mydomain.com/tracking.pl Is this a good idea? I hope so, because I'm using it. Nope, especially when you *can* control the HTTP response headers. This HTML extension is not supported by all browsers. See http://marc.theaimsgroup.com/?l=apache-modperlm=103658812122901w=2 Instead you should use the HTTP headers to do that. The following thread discusses this issue to death: http://marc.theaimsgroup.com/?t=10365327621r=1w=2 __ 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: 2.0 estimated release date?
Jim Martinez wrote: Full of ideas from apachecon and Vegas (cha ching!), I wonder when mod perl 1.99 will become 2.0. Any guesses? Somewhere next year? Though some people are already using it in production. It all depends what functionality is needed, since the core is pretty much done, but there are many angles to polish. Of course since you are talking about the ideas from apachecon, you must be talking about the new features 2.0 provides. Both filters and protocols handlers work and they will probably require some extra tuning as more people start using them. 2.0 does need early adopters, who are willing to try things and be patient to report problems and help workout the solutions. 2.0 needs a lot of real world testing before it will released, something that no test suite can replace. __ 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: make test failed when installing mod_perl 2.0 on Linux
Your attention please: [***] [*** ***] [*** please send the followups back to the list! ***] [*** ***] [***] Thank you! Now to the solutions: Dawn Sun wrote: I've used this patch Index: t/hooks/TestHooks/init.pm === RCS file: /home/cvs/modperl-2.0/t/hooks/TestHooks/init.pm,v retrieving revision 1.3 diff -u -r1.3 init.pm --- t/hooks/TestHooks/init.pm 18 May 2002 02:02:32 - 1.3 +++ t/hooks/TestHooks/init.pm 26 Nov 2002 12:20:03 - @@ -56,6 +56,7 @@ __DATA__ PerlInitHandler TestHooks::init::second Base +PerlModule TestHooks::init PerlInitHandler TestHooks::init::first /Base PerlResponseHandler TestHooks::init But make test failed again. This time, the error changed from the Can't locate TestHooks/init/first.pm in @INC... to Can't locate TestHooks/trans.pm in @INC Other errors remain the same. Good, so probably adding PerlModule TestHook::trans in a similar way (inside Base/Base of t/hooks/TestHooks/trans.pm) should solve that problem too. Though it should have resolved the handlers automatically. You need to enable PERL_TRACE (see the online docs) and post the trace so we can see why these don't get resolved. __ 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: IPC::Open2, mod_perl and cvsweb
Ilya Martynov wrote: On Mon, 25 Nov 2002 18:27:54 +0900, Keith Watanabe [EMAIL PROTECTED] said: KW Hi! KW I was wondering if there are any known issues regarding IPC::Open2 KW with mod_perl. Look in archives. I think many people had problems with IPC::Open2 under mod_perl. So far the best solution I know is just replacing it with IPC::Run. Seconded. Go with IPC::Run and you won't regret, since it works under mod_perl and gives you much more than the IPC::Open* family. __ 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: Subroutine main redefined?
Jan Theofel wrote: Hello, Am Mon, 2002-11-25 um 01.14 schrieb Stas Bekman: Jan Theofel wrote: [Sun Nov 24 17:59:45 2002] shop.pl: Subroutine main redefined at /home/www/[...]/shop/engine/shop.pl line 19. This is a warning, not an error. Ok, but why do I get this warning? I don't redefine the sub. That shouldn't happen. Since under PerlRun the namespace is cleaned before the new request. Any chance you have it defined twice in the same script? Google found some problems and solutions for that, but they all seemed to be for Apache::Registry and not for Apache::PerlRun. ::Registry and ::PerlRun are very similar, most things that apply to the former apply to the latter, see docs for more info. Is ::PerlRun like running ::Registry with the Apache configuration PerlSetVar PerlRunOnce On? Not completely. Docs are coming to help: http://perl.apache.org/docs/1.0/guide/intro.html#Apache__PerlRun That should be: PerlSendHeader on since you manually print your headers. Ok, this works. 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
Re: mod perl 2.0 /Apache 2.0
Rick, mod_perl questions should go to the modperl list. thanks. http://perl.apache.org/maillist/modperl.html Rick Tan wrote: I have been experimenting with mod_perl for the first time in the past week. My frustration level emanates from making old cgi scripts to work with mod_perl/apache 2.0. The scripts were written to be invoked as http://some.server/myscript/other_path? The script name in this case is myscript, other_path is part of the path_info pointing to some data repository on the server. The combination of mod_perl/Apache 2.0 seems to think that the cgi script is called myscript/other_path, it is unable to parse these data. Am I missing some directives for mod_perl to effect this? The same script work with Apache with no mod_perl installed. Does it work with Apache 1.3 or 2.0 using mod_cgi instead of mod_perl? You don't provide the relevant configuration section, so it's hard to tell. __ 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
adding company Foo uses mod_perl ads
As I was leaving Vegas I saw that billboard saying: Adidas uses SAP And I suppose that they run a bunch of similar ads using other big companies names. I think this is an interesting approach of advertising, where instead of advertising the merits of your product or going down on your competitors, you use a concrete example of a well known company that uses your software. So I thought to myself that in addition to our collection of: http://perl.apache.org/outstanding/sites.html http://perl.apache.org/outstanding/success_stories/index.html it'd be interesting to add some small ads similar to the ones used by SAP, though on the left menu bar at perl.apache.org, rather than billboards. e.g. TicketMaster uses mod_perl InternetMovieDatabase uses mod_perl Slashdot uses mod_perl etc. Of course if folks are willing to put them on their sites, that would be great too. But my point here is that when an IT person comes to perl.apache.org but who is still not convinced that mod_perl is something that he wants, this kind of local ads can help to make the right decision :) I guess a simple ImageMagic/GD script that glues the name on the prepared base and doing some color alternation will do the work of making several such ads without manual labour. And then we can randomly spread these at the perl.apache.org pages. Of course it'd be cool to use SVG, but unfortunately we are a long way before major browsers will support it and having users having these newer browsers :( __ 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: mod perl 2.0 /Apache 2.0
[ replies should go to the list and not to me :( ] Rick Tan wrote: It works with Apache 1.3.x/mod_cgi. Apache 2.0/mod_cgi doesn't work either. that's what I thought. Contact the httpd list then as this is not a mod_perl problem: http://httpd.apache.org/lists.html#http-users Stas Bekman wrote: Rick, mod_perl questions should go to the modperl list. thanks. http://perl.apache.org/maillist/modperl.html Rick Tan wrote: I have been experimenting with mod_perl for the first time in the past week. My frustration level emanates from making old cgi scripts to work with mod_perl/apache 2.0. The scripts were written to be invoked as http://some.server/myscript/other_path? The script name in this case is myscript, other_path is part of the path_info pointing to some data repository on the server. The combination of mod_perl/Apache 2.0 seems to think that the cgi script is called myscript/other_path, it is unable to parse these data. Am I missing some directives for mod_perl to effect this? The same script work with Apache with no mod_perl installed. Does it work with Apache 1.3 or 2.0 using mod_cgi instead of mod_perl? You don't provide the relevant configuration section, so it's hard to tell. __ 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 -- __ 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: adding company Foo uses mod_perl ads
Ken Y. Clark wrote: On Tue, 26 Nov 2002, Stas Bekman wrote: advertising the merits of your product or going down on your competitors ^^ For future reference, this phrase has certain ... um ... sexual connotations, at least in the US. :-o And that's exactly what some of them do... without involving implicit sex though ;) __ 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: make error compiling mod_perl on RH7.1
Witchy wrote: Thanks for that, Stas. I'll see if I can get my hands on 5.6.1 since the current release has too many dependencies to resolve with RH7.1 without the possibility of something getting Broken :) Doug says that we want 2.0 to compile under perl 5.6.0, even though you won't get all the features (e.g. perlio, on which other features depend) and you should remember that perl version is very buggy. In any case, if you try the current cvs you should be able to compile 2.0 with 5.6.0 again. -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: 11 November 2002 04:36 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: make error compiling mod_perl on RH7.1 Witchy wrote: Hi all, Trying to compile mod_perl 2.0 for my RH7.1/Apache 2.0.39 server and it falls over with this error: apr_perlio.c: In function `apr_perlio_apr_file_to_glob': apr_perlio.c:573: `IoTYPE_WRONLY' undeclared (first use in this function) apr_perlio.c:573: (Each undeclared identifier is reported only once apr_perlio.c:573: for each function it appears in.) apr_perlio.c:577: `IoTYPE_RDONLY' undeclared (first use in this function) make[3]: *** [apr_perlio.o] Error 1 make[3]: Leaving directory `/home/adrian/mod_perl-1.99_07/xs/APR/PerlIO' make[2]: *** [subdirs] Error 2 make[2]: Leaving directory `/home/adrian/mod_perl-1.99_07/xs/APR' make[1]: *** [subdirs] Error 2 make[1]: Leaving directory `/home/adrian/mod_perl-1.99_07/xs' make: *** [subdirs] Error 2 When I ran 'perl Makefile.PL' etc with the correct location for my apache setup the only thing it complained about was the fact I was using Perl 5.6.0 and it recommended 5.6.1 or above. Before I trawl the dependencies tree trying to install a later version has anyone seen that problem before and do I really need to upgrade my perl installation? As somebody else has pointed out you won't have a problem if you run Perl 5.6.1 or higher. Let me check with other developers if 2.0 will eventually require 5.6.1 which is much better thatn 5.6.0. Or whether we should backport things to 5.6.0 as well. The reason is that macros IoTYPE_WRONLY and IoTYPE_RDONLY were introduced in 5.6.1. __ 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 -- __ 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: How Can I Install ModPerl on My ISP-based Website???
David Simcik wrote: Thanks for the link... So basically, according to the link listed below, there IS NO good way to install modperl for just a local user account (I can't work some .htaccess magic,etc.?)? I guess that would make sense -- seems like modperl is tightly bound with the apache installation (one of dem dere apache modules I take it). The memory/resource issues mentioned on that page facing ISPs seem a bit justified as well. Sigh. You will probably need to have an installation per user if security is an issue. Various possible solutions are discussed in that doc. mod_perl 2.0 with perchild mpm should resolve the ownership problem, partially similar to what suexec does. David -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 11:30 AM To: David Simcik Cc: Modperl Subject: Re: How Can I Install ModPerl on My ISP-based Website??? David Simcik wrote: I would LOVE to use mod_perl on my personal website -- I have the diskspace to do so, but the question remains as to whether or not I have the rights. The rights to do what? Can anyone point me to a guide for this? I've poked around the mod_perl site and didn't find anything too specific. My guess would be: http://perl.apache.org/docs/general/multiuser/multiuser.html _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ -- __ 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: passing Apache::Request object
Marc Lambrichs wrote: Hi All, I want to save my Apache::Request object in an PerlInitHandler called Initialization and later on during the life cycle of the request call a Initialization-get_request() method to use it again. perldoc Apache::Request: instance The instance() class method allows Apache::Request to be a singleton. This means that whenever you call Apache::Request-instance() within a single request you always get the same Apache::Request object back. This solves the problem with creating the Apache::Request object twice within the same request - the symptoms being that the second Apache::Request object will not contain the form parameters because they have already been read and parsed. my $apr = Apache::Request-instance($r, DISABLE_UPLOADS = 1); [... more in the manpage ...] __ 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: Where do you specify APR::HOOK...
Erich Oliphant wrote: Ok, thanks now it makes sense ;) It's in the mp2 docs and it wasn't clear if it was not implemeted or the docs were behind the code. Maybe you guys could stick a note on it or something. done. - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Erich Oliphant [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, November 11, 2002 5:45 AM Subject: Re: Where do you specify APR::HOOK... Erich Oliphant wrote: Hi, I am trying to place a handler at the end of the list of PerlLogHandler's. I know I want to use APR::HOOK_REALLY_LAST but I'm not sure how or where to specify it for my handler. I tried PerlLogHandler My::Handler APR::HOOK_REALLY_LAST in the httpd.conf file w/ no success. Should it be in the handler code itself? That API doesn't exist yet in mod_perl 2.0. I believe the reason for that is that Apache hooks ordering API wasn't finalized yet. __ 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 -- __ 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: Problem using variable with @PerlSetVar
Christopher Grau wrote:
Hi,
I have a fairly simple problem, but haven't had much luck finding the
solution on Google or the mailing list archives. Basically, I have this
code in httpd.conf:
Perl
print Enter some value you don't want written down: ;
my $value = STDIN;
chomp $value;
print value = '$value'\n;
# The code works if I do this...
# $value = Foobar;
push @PerlSetVar, [Foo = $value];
/Perl
The value in $value prints to stdout, but the variable Foo doesn't get
set to $value. However, if I were to set $value to something
explicitly, as in the comment above, the code works fine.
Based on that, I'm guessing the problem lies with reading from STDIN.
What am I missing here?
This one was tricky. The reason for this misterious behavior lies in
fact that Apache restarts itself on start. The STDIN input is prompted
once and then on the restart $value gets overwritten with undef. If you
check your error_log you will see several warnings and errors regarding
this code. among which:
[Sun Nov 24 19:45:40 2002] [error] (25)Inappropriate ioctl for device:
Perl: PerlSetVar takes two arguments, Perl config var and value
First of all, it's easier to debug with:
Perl
use Apache::PerlSections();
$Apache::Server::SaveConfig = 1;
# set @Perl* here
print STDERR Apache::PerlSections-dump();
/Perl
notice the dump(). Remember that on start STDERR goes to the console. On
the restart it goes to error_log, therefore you want to watch both, as
it will be called twice.
using the dump() you will see that on restart no value is passed.
Here are two possible solution that work:
print Enter some value you don't want written down: ;
$mytmp::value ||= STDIN;
chomp $mytmp::value;
print value = '$mytmp::value'\n;
push @PerlSetVar, [Foo = $mytmp::value];
here, we use a global variable, so it survives the scope re-entrance. If
STDIN may return 0, you want to do:
$mytmp::value = STDIN unless defined $mytmp::value;
instead
Another longer but more self-documenting solution is as follows:
if ($Apache::Server::Starting) {
print Enter some value you don't want written down: ;
$mytmp::value = STDIN;
chomp $mytmp::value;
} else {
print value = '$mytmp::value'\n;
push @PerlSetVar, [Foo = $mytmp::value];
}
See also:
http://perl.apache.org/docs/1.0/guide/config.html#Apache_Restarts_Twice_On_Start
p.s. for now let's keep this trickery in the archives, if the question
is repeated, will add the answer to the docs.
__
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: Reading configuration problem under mod_perl2
Yuriy Syrota wrote: Hello, folks. I'm porting apache module (from version 1 to version 2) and got the following problem: The module can't read itself configuration from httpd.conf. I traced out ap_find_command_in_modules() in httpd and realized that in this function modules list doesn't contain my module's entry. Although httpd calls my per-server configuration creator. How can it be? Just to make things clear, does this happen when you load modperl and works fine without it? __ 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: How sub handler was called.
Stas Bekman wrote: Ruslan U. Zakirov wrote: Hello, all! May I understand in my handler sub how it was called? Was it called by Apache process in stacked handlers chain or it was called by some other module with call MyMod::handler($r)? Could i do it without adding some special parametrs? perldoc caller perldoc -f caller Thanks, Issac __ 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: MySQL prepared sql statements?
David Wheeler wrote: On Sunday, November 24, 2002, at 01:08 PM, Bas A.Schulte wrote: I'm wondering if I would gain (some) performance by preparing my sql statements once during ChildInit when using MySQL? Does it cache execution plans for sql statements? I know it makes a big difference on Oracle but I'm not sure what MySQL is like in this respect. MySQL doesn't have a prepared statement feature, so you wouldn't get the same kind of performance gain that you would with Oracle. That said, DBD::mysql does a bit of munging with your statements, and if you use prepare(), it does that munging only once per statement. The upshot: Use prepare() whenever possible to maximize performance. Even better, used prepare_cached() for statements you'll be using a lot, and then they'll be prepared only the first time prepare() is called (per Apache child). Doing so will also make it easier to gain the performance benefit if you later decide to switch to a database such as Oracle that supports prepared statements in the database. What David said, plus your friendly docs: http://perl.apache.org/search/swish.cgi?query=prepare_cachedsbm=SecEsubmit=search __ 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: Subroutine main redefined?
Jan Theofel wrote:
Hello,
I have a very simple perl script which I try to run with
Apache::PerlRun. After changing the directory section in the apache
configuration file and a restart I get no repsonse to my client and the
error file fills with:
[Sun Nov 24 17:59:45 2002] shop.pl: Subroutine main redefined at
/home/www/[...]/shop/engine/shop.pl line 19.
This is a warning, not an error.
Google found some problems and solutions for that, but they all seemed
to be for Apache::Registry and not for Apache::PerlRun.
::Registry and ::PerlRun are very similar, most things that apply to the
former apply to the latter, see docs for more info.
Here's the script (a few comments snipped away):
--- snip ---
#!/usr/bin/perl -w
use strict;
use eqtools;
use eqdbtools;
main;
1;
sub main {
# -- create a new session --
open_db();
my $sid = create_session();
track_request($sid, ?THIS_IS_A_NEW_SESSION);
close_db();
# -- forward the browser to the following page --
if($sid ne )
{
print Status: 302 Moved\n;
print Location: /static.pl?sid=$sidpage=home\n\n;
}
else
{
fatal_db_error(FATAL ERROR CREATING A NEW SESSION!, -);
}
}
--- snap ---
And here is the section form my apache configuration file:
--- snip ---
Directory /home/www/[...]/shop/engine
AllowOverride AuthConfig
Order allow,deny
Allow from all
SetHandler perl-script
PerlHandler Apache::PerlRun
Options +ExecCGI -Includes
PerlSendHeader off
That should be:
PerlSendHeader on
since you manually print your headers.
__
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: Problem with Stream-oriented Output Filter
Esteban Fernandez Stafford wrote: [...] As you can see the filter is called twice and therefore there is one line that gets broken in two. I could always store $left_over in the context of the filter and prepend it to what I read when the filter starts again. But the problem I find is that I have no way to know when the real eos is reached in order to flush $left_over to the output. I thought there may be some sort of $filter-eos() call or something. Yes, there is a problem. Thanks for the report! If you are on the dev list we discuss how exactly to implement a good solution. If not I'll post the solution once we have one. __ 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: [OT] Stack Operation
Tim Tompkins wrote: But push()ing and pop()ing is not what the original poster wants to do. He wants to splice(). It doesn't matter if he's talking about treating a stack in the traditional sense, and it doesn't matter that splice is not as efficient as push or pop. What matters is that he knows how to accomplish what he requested. Any chance you can find a more appropriate forum for discussing perl basic things? Thank you! __ 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: Static mod-perl with apache 1.3.27 on OS 10.2.2
Randall Perry wrote: Trying to compile static mod-perl using the following configs. You don't say what configs. Please review the build process at: http://perl.apache.org/docs/1.0/guide/install.html moreover when reporting problems make sure to follow these guidelines: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems (hint: look at the shortcuts menu on the left at all pages on perl.apache.org) Everything runs without error, except libperl.a is never built in apache_1.3.27/src/modules -- get the following error: === src/modules/libperl.a /bin/sh: cd: libperl.a: No such file or directory Can someone help? -- __ 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: Migrating from CGI.pm to Apache::Request question.
Jesse Erlbaum wrote: Hi Coexec -- I am experienced with using the CGI.pm, and now I want to rewrite all of my CGI's using mod_perl and Apache::Request. Maybe a silly question: What are you hoping to gain by doing this? Speed. Apache::Request's guts are implemented in C, CGI.pm is Perl. If you do a lot of processing the speed improvement is significant. See: http://perl.apache.org/docs/1.0/guide/performance.html#Apache__args_vs__Apache__Request__param_vs__CGI__param _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: make test failed when installing mod_perl 2.0 on Linux
please remember to properly report problems, as explained at: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems (hint: the shortcuts menu on the left side of any page of perl.apache.org) if you don't provide all the required details it makes it hard to guess what configuration you've the problem with. I had this problem a while ago with the worker mpm over 5.8.0: http://marc.theaimsgroup.com/?l=apache-modperl-devm=101128927611980w=2 but I think it should be OK now. I am new to linux and mod_perl. We are running perl 5.8.0 and apache 2.0.43 on linux. First time we are trying to install mod_perl2. But the make test failed completed. Here is the error_log reads: END in modperl_extra.pl, pid=19385 [Thu Nov 21 11:24:45 2002] [notice] Apache/2.0.43 (Unix) mod_perl/1.99_07-dev Perl/v5.8.0 configured -- resuming normal operations [Thu Nov 21 11:24:45 2002] [info] Server built: Nov 20 2002 15:10:20 [Thu Nov 21 11:24:45 2002] [debug] prefork.c(1039): AcceptMutex: sysvsem (default: sysvsem) [Thu Nov 21 11:24:46 2002] [error] Can't locate TestHooks/init/first.pm in @INC (@INC contains: /home/dsun/mod_perl-1.99_07/t /home/dsun/mod_perl-1.99_07/blib/lib/Apache2 /home/dsun/mod_perl-1.99_07/blib/arch/Apache2 /home/dsun/mod_perl-1.99_07/Apache-Test/lib /home/dsun/mod_perl-1.99_07/lib /home/dsun/mod_perl-1.99_07/blib/lib /home/dsun/mod_perl-1.99_07/blib/arch /home/dsun/mod_perl-1.99_07/t/response /home/dsun/mod_perl-1.99_07/t/protocol /home/dsun/mod_perl-1.99_07/t/hooks /home/dsun/mod_perl-1.99_07/t/filter /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/perlmodule-vh /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/main /usr/local/lib/perl5/5.8.0/i586-linux /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i586-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl) at (eval 23) line 3. [Thu Nov 21 11:24:46 2002] [error] failed to resolve handler `TestHooks::init::first' [Thu Nov 21 11:24:46 2002] [error] [client 127.0.0.1] Can't locate TestHooks/init/first.pm in @INC (@INC contains: /home/dsun/mod_perl-1.99_07/t /home/dsun/mod_perl-1.99_07/blib/lib/Apache2 /home/dsun/mod_perl- . [Thu Nov 21 11:26:32 2002] [error] failed to resolve handler `TestHooks::init::first' [Thu Nov 21 11:26:34 2002] [error] failed to resolve handler `TestHooks::init::first' [Thu Nov 21 11:27:27 2002] [error] Can't locate TestProtocol/echo.pm in @INC (@INC contains: /home/dsun/mod_perl-1.99_07/t /home/dsun/mod_perl-1.99_07/blib/lib/Apache2 /home/dsun/mod_perl-1.99_07/blib/arch/Apache2 /home/dsun/mod_perl-1.99_07/Apache-Test/lib /home/dsun/mod_perl-1.99_07/lib /home/dsun/mod_perl-1.99_07/blib/lib /home/dsun/mod_perl-1.99_07/blib/arch /home/dsun/mod_perl-1.99_07/t/response /home/dsun/mod_perl-1.99_07/t/protocol /home/dsun/mod_perl-1.99_07/t/hooks /home/dsun/mod_perl-1.99_07/t/filter /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/perlmodule-vh /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/main /usr/local/lib/perl5/5.8.0/i586-linux /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i586-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl) at (eval 25) line 3. [Thu Nov 21 11:27:27 2002] [error] failed to resolve handler `TestProtocol::echo' [Thu Nov 21 11:27:27 2002] [error] Can't locate TestProtocol/echo.pm in @INC (@INC contains: /home/dsun/mod_perl- [Thu Nov 21 11:27:29 2002] [error] Can't locate TestProtocol/echo_filter.pm in @INC (@INC [Thu Nov 21 11:27:29 2002] [error] failed to resolve handler `TestProtocol::echo_filter' [Thu Nov 21 11:27:29 2002] [error] Can't locate TestProtocol/echo_filter.pm in @INC (@INC . [Thu Nov 21 11:27:29 2002] [info] removed PID file /home/dsun/mod_perl-1.99_07/t/logs/httpd.pid (pid=19387) [Thu Nov 21 11:27:29 2002] [notice] caught SIGTERM, shutting down END in modperl_extra.pl, pid=19387 I've checked the actual module in @INC. It does exist. Then I've searched throu the mod_perl archive, and made the change as http://www.mail-archive.com/modperl@apache.org/msg29648.html suggested. But make test failed again. This time, the error changed from the Can't locate TestHooks/init/first.pm in @INC... to Can't locate TestHooks/trans.pm in @INC Other errors remain the same. Any suggestions? Dawn -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: How Can I Install ModPerl on My ISP-based Website???
David Simcik wrote: I would LOVE to use mod_perl on my personal website -- I have the diskspace to do so, but the question remains as to whether or not I have the rights. The rights to do what? Can anyone point me to a guide for this? I've poked around the mod_perl site and didn't find anything too specific. My guess would be: http://perl.apache.org/docs/general/multiuser/multiuser.html _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: libperl.so: undefined symbol: PL_dowarn
Dennis wrote: Hi, I have compiled mod_perl en installed it without any errors but wen i try to start Apache witch mod_perl then i get the following error: Starting Apache 1.3.27: Syntax error on line 274 of /opt/apache-1.3.27/conf/httpd.conf: Cannot load /opt/apache/libexec/libperl.so into server: /opt/apache/libexec/libperl.so: undefined symbol: PL_dowarn /opt/apache/bin/apachectl startssl: httpd could not be started As gozer suggest next to me, you might have a stray header file from an older perl, which happened to be picked by the build. Any chance you have a few installations of perl? Trying install from scratch? -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Problem with Stream-oriented Output Filter
Esteban Fernandez Stafford wrote:
Hello,
I am currently developing a modperl filter that uses the streaming
approach. I started off with the example in
http://perl.apache.org/docs/2.0/user/handlers/filters.html#Stream_oriented_Output_Filter
sub handler {
my $filter = shift;
my $left_over = '';
while ($filter-read(my $buffer, BUFF_LEN)) {
$buffer = $left_over . $buffer;
$left_over = '';
while ($buffer =~ /([^\r\n]*)([\r\n]*)/g) {
$left_over = $1, last unless $2;
$filter-print(scalar(reverse $1), $2);
}
}
$filter-print(scalar reverse $left_over) if length $left_over;
Apache::OK;
}
This seems to work OK when the file is small (smaller than 8192). When
the file is larger, then there is a line that gets cut. This is
because the handler gets called more than once for big requests. Is
there a nice way to overcome this problem? I was thinking using
filter context to store variable $left_over, but then I dont know how
to detect the real end of the stream.
The problem is that I've written a patch that makes the $filter-print()
outside the while() loop work, but it was never committed. So the doc
is out of sync with the core code. For now please apply this patch:
http://marc.theaimsgroup.com/?l=apache-modperl-devm=102828686110352w=2
I'll see that it gets into the core asap.
--
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: am i heading for disaster... ?
Noam Solomon wrote:
In the process of building apache_1.3.27 / mod_perl 1.3.27 /
openssl0.9.6g / mod_ssl mod_ssl-2.8.12-1.3.27 on a Solaris OS 2
UltraSparc, with Perl 5.8, the apache make failed because of an
undefined url_delims. I was using the method where you build mod_ssl,
then build mod_perl, then configure apache, loading mod_perl statically.
Anyway, I poked around and found that indeed the uri_delims.h file in
src/main was empty! So still in src/main, I manually ran gcc
gen_uri_delims.c, then ran a.out uri_delims.h to regenerate that
header file, and got this.
/* this file is automatically generated by gen_uri_delims, do not
edit */
static const unsigned char uri_delims[256] = {
T_NUL,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,T_HASH,0,0,0,0,
0,0,0,0,0,0,0,T_SLASH,0,0,0,0,0,0,0,0,0,0,T_COLON,0,
0,0,0,T_QUESTION,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
};
Then when I ran make again, everything was hunky-dory. Now what I want
to know is, why would this have happened in the first place? Is it a
sign that something is fundamentally wrong with the build, but I just
haven't seen it yet? Or should I just breathe easy and hope for the best?
I doubt this has anything to do with mod_perl. The build hasn't changed
in years, so it must be some external glitch. For example you might have
run out of disk space, so when it was writing the file it was zeroed.
--
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: References for modperl usage in financial institutions?
Marcin Kasperski wrote: Thanks for all the people who sent me the references (both here and to private email). Maybe it would be good idea to add some such references to the 'sites running modperl' page. My business client after taking a look at http://perl.apache.org/outstanding/sites.html said 'nice, but there are mostly technical sites, almost no business...' Yes, please post your success stories here and we will add them to http://perl.apache.org/outstanding/sites.html or http://perl.apache.org/outstanding/success_stories/index.html depending on how descriptive the story is. Looking forward to add your stories... _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
