Re: mod_perl survey results
André Warnier wrote: The responses there are indeed a bit scary. It feels like we're a dying breed. I believe this is to a large extent a "marketing issue" for perl in general, and mod_perl by extension, with regard to the younger programmers generation. At least in various European countries I know, perl is not really being taught in programming schools as a "serious" programming language for applications. These young people have all heard the name, but seem to consider it as a powerful but somewhat messy scripting language to create system administration scripts. I am personally doing my best to introduce these newbies to the beauties of perl and mod_perl, but it feels rather lonely sometimes. Java and PHP seem definitely more popular, or better-known. I agree that this does echo perl's problems in general, but mod_perl has a long history of not really being very good at marketing itself. I know Perrin and some other people did try at the launch of mod_perl2, but that effort (and the associated mailing list) has long since dried up. - A surprising number of people are running mod_perl under the worker MPM. What is so surprising about this ? (genuine curious question) It's surprising to me, and probably to Torsten, because the perceived common wisdom is to run prefork, because worker may or may not be as well tested, and has all the bonus issues related to thread-safeness. - the documentation could use some work. Specifically more tutorial / intro kind of stuff. Agreed. There is a definite need also for something like a new mod_perl Guide and Cookbook all-in-one, updated for mod_perl 2 and with a section about the framework/template systems mentioned above. Written in a style meant to show that these are not old-fashioned technologies only practised by oldies like me (us?). What I mean is that to cover all one needs to know to create some serious web applications in Java, you'd need at least 6 thick volumes, while for Perl 800-1000 pages would be more than enough. O'Reilly, where are you ? Honestly, I think this stuff is currently better handled by the community. As such, i'm going to take a stab at writing some very basic intro / tutorial kind of documentation to be added to perl.apache.org. When i started with mod_perl 1, the Guide on thought the "guide" perl.apache.org was amazing, but it seems to me that mod_perl 2 doesn't have that in the same way. Much of the content has been ported over to the 2.0 section, but there are many pages that haven't been updated from the 1.0 tree at all. Adam
Re: Substituting URLs in PerlOutputFilterHandler
Puneet Lakhina wrote: Hi, I am trying to write a handler that modifies the content of the page based on a regex match. essentially im trying to modify tags in the outgoing HTML pages. Now I am trying to do this using PerlOutputFilterHandler. I have the following questions: a) Is this the right filter to use for an application like this? b) As per my understanding my hander can be invoked multiple times based on the no. of buckets. Is this correct? If yes, then how should I handle the situation where a part of the tag like say '' comes in another. This is exactly the situation that Apache2::Filter::TagAware was built for. http://search.cpan.org/~aprime/Apache2-Filter-TagAware-0.02/lib/Apache2/Filter/TagAware.pm Adam
Re: mod_perl survey results
Steven Siebert wrote: I'm relatively new to mod_perl - moving to a new job who's application is solely written in it. This is a return to Perl for me, having worked in PHP, Java, and .NET since Perl 4. As I'm learning to love mod_perl and Perl in general, perhaps it's a good time for me to contribute back by writing perl/mod_perl blogs and tutorials to help others easing in from other languages (written with a set of assumptions). I've seen the "to-do" list, if you will, on the mod_perl Advocacy page (http://perl.apache.org/docs/general/advocacy/advocacy.html) but not sure how dated this is or what is the best to tackle. That page probably dates back to late 2004, which is when mod_perl 2 actually hit the streets, and the last time the advocacy mailing list saw any sort of usage. The mp-advocacy archives can been seen here: http://marc.info/?l=apache-modperl-advocacy&r=1&w=2, and is, as you noticed, pretty much dead. I'm not in any way the boss of this sort of stuff, but i'd say if you want to bring anything up, you should probably bring it up here. If, by some miracle advocacy talk (and even better work), starts getting too chattery on this list, then it could be moved. I think people blogging about mod_perl would be great, but personally, I think that the best place for tutorials is ultimately on perl.apache.org. Let me know how to get involved - it is my job security after all =). Seriously, though, the flexibility of mod_perl is just not available in many of the other languages and I think it's "don't know what you don't know" sort of thing...so much work is done in the application code when it could be solved with a few lines using mod_perl at the httpd abstract layer. I have a blog site but if perl.apache.org desires host tutorials and blogs, so much the better (better discoverability). http://perl.apache.org/contribute/ has some pointers about different ways you can help, but this page too probably hasn't been updated in years. I think you're absolutely right about the "don't know what you don't know thing". If more people we're blogging about problems they'd defeated with mod_perl it couldn't hurt the situation, at least IMO. I believe that most, if not all, of perl.apache.org is built out of the /modperl-docs/ SVN repository. Adam
Re: mod_perl survey results
Ok guys, I'm nowhere as good a programmer as many people on this list, but a) I do have patience with beginners, b) I'm convinced and c) maybe I can do something in terms of documentation, if only to fix missing links. And d) I'd love to see my name somewhere as a contributor, even at the very end and in small font. So, where do I start ? Steven Siebert wrote: I'm relatively new to mod_perl - moving to a new job who's application is solely written in it. This is a return to Perl for me, having worked in PHP, Java, and .NET since Perl 4. As I'm learning to love mod_perl and Perl in general, perhaps it's a good time for me to contribute back by writing perl/mod_perl blogs and tutorials to help others easing in from other languages (written with a set of assumptions). I've seen the "to-do" list, if you will, on the mod_perl Advocacy page (http://perl.apache.org/docs/general/advocacy/advocacy.html) but not sure how dated this is or what is the best to tackle. Let me know how to get involved - it is my job security after all =). Seriously, though, the flexibility of mod_perl is just not available in many of the other languages and I think it's "don't know what you don't know" sort of thing...so much work is done in the application code when it could be solved with a few lines using mod_perl at the httpd abstract layer. I have a blog site but if perl.apache.org desires host tutorials and blogs, so much the better (better discoverability). I've also noticed the mod_perl advocacy mailing list is all but dead. Perhaps this is the best channel to bring these issues up? Regards, Steve On Mon, Nov 10, 2008 at 8:59 AM, Adam Prime <[EMAIL PROTECTED]> wrote: André Warnier wrote: The responses there are indeed a bit scary. It feels like we're a dying breed. I believe this is to a large extent a "marketing issue" for perl in general, and mod_perl by extension, with regard to the younger programmers generation. At least in various European countries I know, perl is not really being taught in programming schools as a "serious" programming language for applications. These young people have all heard the name, but seem to consider it as a powerful but somewhat messy scripting language to create system administration scripts. I am personally doing my best to introduce these newbies to the beauties of perl and mod_perl, but it feels rather lonely sometimes. Java and PHP seem definitely more popular, or better-known. I agree that this does echo perl's problems in general, but mod_perl has a long history of not really being very good at marketing itself. I know Perrin and some other people did try at the launch of mod_perl2, but that effort (and the associated mailing list) has long since dried up. - A surprising number of people are running mod_perl under the worker MPM. What is so surprising about this ? (genuine curious question) It's surprising to me, and probably to Torsten, because the perceived common wisdom is to run prefork, because worker may or may not be as well tested, and has all the bonus issues related to thread-safeness. - the documentation could use some work. Specifically more tutorial / intro kind of stuff. Agreed. There is a definite need also for something like a new mod_perl Guide and Cookbook all-in-one, updated for mod_perl 2 and with a section about the framework/template systems mentioned above. Written in a style meant to show that these are not old-fashioned technologies only practised by oldies like me (us?). What I mean is that to cover all one needs to know to create some serious web applications in Java, you'd need at least 6 thick volumes, while for Perl 800-1000 pages would be more than enough. O'Reilly, where are you ? Honestly, I think this stuff is currently better handled by the community. As such, i'm going to take a stab at writing some very basic intro / tutorial kind of documentation to be added to perl.apache.org. When i started with mod_perl 1, the Guide on thought the "guide" perl.apache.org was amazing, but it seems to me that mod_perl 2 doesn't have that in the same way. Much of the content has been ported over to the 2.0 section, but there are many pages that haven't been updated from the 1.0 tree at all. Adam
Re: mod_perl survey results
On Mon, Nov 10, 2008 at 6:46 AM, André Warnier <[EMAIL PROTECTED]> wrote: >>> - A surprising number of people are running mod_perl under the worker >>> MPM. > > What is so surprising about this ? (genuine curious question) Because of the way perl threads use memory, you end up using less a lot less memory with prefork than with threads on Linux/BSD. This has been discussed on the mailing list many times. The only platform where I expect to see people use threads is Windows, since they have no choice there. - Perrin
Re: mod_perl survey results
More memory but potentially faster, correct? Since we don't have to spawn as many processes to accommodate a load? Although i don't use worker MPM since the codebase I adopted is not thread safe, I would investigate if it was an option. Memory is fairly cheap and, with my web servers (without DB's on it - just web servers) with 32 gigs of RAM.speed is more important. Plus, of course, "threads" ge "optimization silver bullet"right? =) On Mon, Nov 10, 2008 at 11:16 AM, Perrin Harkins <[EMAIL PROTECTED]> wrote: > On Mon, Nov 10, 2008 at 6:46 AM, André Warnier <[EMAIL PROTECTED]> wrote: - A surprising number of people are running mod_perl under the worker MPM. >> >> What is so surprising about this ? (genuine curious question) > > Because of the way perl threads use memory, you end up using less a > lot less memory with prefork than with threads on Linux/BSD. This has > been discussed on the mailing list many times. The only platform > where I expect to see people use threads is Windows, since they have > no choice there. > > - Perrin >
Re: mod_perl survey results
Perrin Harkins wrote: On Mon, Nov 10, 2008 at 6:46 AM, André Warnier <[EMAIL PROTECTED]> wrote: - A surprising number of people are running mod_perl under the worker MPM. What is so surprising about this ? (genuine curious question) Because of the way perl threads use memory, you end up using less a lot less memory with prefork than with threads on Linux/BSD. This has been discussed on the mailing list many times. The only platform where I expect to see people use threads is Windows, since they have no choice there. - Perrin Maybe this is the time to ask. I am using Linux Debian, and getting Apache 2, perl and mod_perl 2 from there (apt-get). I have never been quite sure which mpm the packager decided to configure, as the apache2.conf contains parameters for prefork, pthread and perchild. So, a) which is the best way to find out ? b) if it happened to be "worker" or something, could I just change that to "prefork", or is there more to it ? (Also so far, even if it is using a threaded mpm, it does not seem to have any deleterious effect on my systems, which are pretty stable). Thanks
Re: mod_perl survey results
Rolf Schaufelberger wrote: Hi Adam, quite interesting. Thanks for doing all that work. Thanks too. Interesting indeed. Am Montag, 10. November 2008 03:59:13 schrieb Adam Prime: The results of the mod_perl survey that Fred Moyer and I conducted can be found at the following link: http://kabob.ca/mod_perl_survey/ Here's a quick list of obvious (though arguable) conclusions: - a lot of people have switched to mod_perl 2, mod_perl 1 is still very significant. - most of the people using mod_perl have been using it for a long time. - the rate of new people coming into the community has been declining. The responses there are indeed a bit scary. It feels like we're a dying breed. I believe this is to a large extent a "marketing issue" for perl in general, and mod_perl by extension, with regard to the younger programmers generation. At least in various European countries I know, perl is not really being taught in programming schools as a "serious" programming language for applications. These young people have all heard the name, but seem to consider it as a powerful but somewhat messy scripting language to create system administration scripts. I am personally doing my best to introduce these newbies to the beauties of perl and mod_perl, but it feels rather lonely sometimes. Java and PHP seem definitely more popular, or better-known. - linux is by far the most popular platform. the BSD's, Solaris and Windows also make a significant showing. Not enough people know that Perl is at least as multi-platform as Java, and much lighter. - Fred and I didn't really break down frameworks very well, but mason, Catalyst and CGI::Application are quite popular. TT is also very popular, but not exactly a framework, but not quite as popular is old fashioned Handlers. - A surprising number of people are running mod_perl under the worker MPM. What is so surprising about this ? (genuine curious question) - Most of the Handler phases are getting some use. - There are a lot of people using CGI Emulation, which is not a surprise. - not very many people are using the mod_perl2 filter api. - there is quite a bit of interest in a mod_perl Workshop, but location would be a key factor for a lot of people - the documentation could use some work. Specifically more tutorial / intro kind of stuff. Agreed. There is a definite need also for something like a new mod_perl Guide and Cookbook all-in-one, updated for mod_perl 2 and with a section about the framework/template systems mentioned above. Written in a style meant to show that these are not old-fashioned technologies only practised by oldies like me (us?). What I mean is that to cover all one needs to know to create some serious web applications in Java, you'd need at least 6 thick volumes, while for Perl 800-1000 pages would be more than enough. O'Reilly, where are you ? Stas Beckman's mod_perl 2 book is good, but I believe only really accessible to people who already know perl and mod_perl quite well. The CPAN library is incredibly rich, and the documentation of most modules is a superb source of information on a lot of things, even apart from the pure perl aspect of it. But the main issue I believe is that younger programmers don't even go looking there, because they are intimidated by perl. It's a pity. Maybe there isn't much to do about it though, except feeling nostalgia. Both Java and PHP have a few commercial organisations behind them to promote them, while Perl doesn't really. Maybe that's the difference in the long term. I work for a small company, and we know that using perl and mod_perl and CPAN and Apache, we can do things that would be out of our reach otherwise. So we know we're on to a good thing for ourselves, but it is not really enough to make these things more popular on a broad scale.
Re: comment regarding documentation
Ian Goodacre wrote: I would be helpful if the Introducing mod_perl Handlers page at http://perl.apache.org/docs/2.0/user/handlers/intro.html included a section describing the arguments to the handler functions and if the description of the handlers (PerlResponseHandler in particular) included a link to the existing descriptions where they are not in the sections. I have found the information. It is there but it could be easier to find with just one or two more links. Patches welcome :) -- Philip M. Gollucci ([EMAIL PROTECTED]) c: 703.336.9354 Consultant - P6M7G8 Inc. http://p6m7g8.net Senior System Admin - RideCharge, Inc. http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: mod_perl survey results
On Mon, Nov 10, 2008 at 11:28 AM, Steven Siebert <[EMAIL PROTECTED]> wrote: > More memory but potentially faster, correct? Since we don't have to > spawn as many processes to accommodate a load? No, there's no speed advantage to threads. In fact perl is measurably faster if you compile it with no thread support. > Memory is fairly cheap and, with my > web servers (without DB's on it - just web servers) with 32 gigs of > RAM.speed is more important. Memory isn't cheap enough to ignore. It limits the number of backends you can run and the amount of caching you can do. Being careful with memory will get a lot more scalability out of your hardware. - Perrin
Re: mod_perl survey results
André Warnier wrote: Maybe this is the time to ask. I am using Linux Debian, and getting Apache 2, perl and mod_perl 2 from there (apt-get). I have never been quite sure which mpm the packager decided to configure, as the apache2.conf contains parameters for prefork, pthread and perchild. So, a) which is the best way to find out ? b) if it happened to be "worker" or something, could I just change that to "prefork", or is there more to it ? (Also so far, even if it is using a threaded mpm, it does not seem to have any deleterious effect on my systems, which are pretty stable). Thanks ./httpd -V Server version: Apache/2.0.54 Server built: Sep 25 2005 00:31:31 Server's Module Magic Number: 20020903:9 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" ... The -D APACHE_MPM_DIR tells you which MPM your apache is using. In order to change MPM's you need to recompile apache, and quite possibly mod_perl as well, i have no idea how you'd accomplish that on debian using apt.
Re: mod_perl survey results
On Mon 10 Nov 2008, Steven Siebert wrote: > Let me know how to get involved How well is your C? There is a segfault waiting to be hunted down. It's one of the nicer. It happens each time the test suite runs with worker MPM. If interested I can give you further information. The threading branch at http://svn.apache.org/repos/asf/perl/modperl/branches/threading needs a few ifdefs to work with perls without threading support. That branch is also a good starting point for the segfault above. Try out the threading branch with the Windows MPM. I don't have Windows (and don't care much). So there may be a lot to do. Further on the line I have a few ideas how to make modperl consume less memory when running under a threaded MPM. I think we really need better threading support to survive. We can of course repeat the mantra "use prefork" ever again. But many apache developers tend to use a threaded MPM as default. Some days ago Paul Querna even asked how valuable copy-on-write is and if it can be dropped in favor of better Windows compatibility. The day will come when prefork is not the default MPM even on Unix-like systems. Of course there is always a need for advocacy, writing papers, presentations, case studies, cool solutions etc. Torsten -- Need professional mod_perl support? Just hire me: [EMAIL PROTECTED]
Re: mod_perl survey results
On Mon 10 Nov 2008, André Warnier wrote: > Ok guys, I'm nowhere as good a programmer as many people on this > list, but a) I do have patience with beginners, b) I'm convinced and > c) maybe I can do something in terms of documentation, if only to fix > missing links. And d) I'd love to see my name somewhere as a > contributor, even at the very end and in small font. > So, where do I start ? c) See http://perl.apache.org/contribute/index.html. Lately there have been a few complains about missing, incomplete or misleading docs on the list. You could start to submit patches. A simple one could be this: http://www.gossamer-threads.com/lists/modperl/dev/98380. Find out why it was that way in the first place then patch it. Torsten -- Need professional mod_perl support? Just hire me: [EMAIL PROTECTED]
Re: mod_perl survey results
Hi Adam, quite interesting. Thanks for doing all that work. Am Montag, 10. November 2008 03:59:13 schrieb Adam Prime: > The results of the mod_perl survey that Fred Moyer and I conducted can > be found at the following link: > > http://kabob.ca/mod_perl_survey/ > > Here's a quick list of obvious (though arguable) conclusions: > > - a lot of people have switched to mod_perl 2, mod_perl 1 is still very > significant. > - most of the people using mod_perl have been using it for a long time. > - the rate of new people coming into the community has been declining. > - linux is by far the most popular platform. the BSD's, Solaris and > Windows also make a significant showing. > - Fred and I didn't really break down frameworks very well, but mason, > Catalyst and CGI::Application are quite popular. TT is also very > popular, but not exactly a framework, but not quite as popular is old > fashioned Handlers. > - A surprising number of people are running mod_perl under the worker MPM. > - Most of the Handler phases are getting some use. > - There are a lot of people using CGI Emulation, which is not a surprise. > - not very many people are using the mod_perl2 filter api. > - there is quite a bit of interest in a mod_perl Workshop, but location > would be a key factor for a lot of people > - the documentation could use some work. Specifically more tutorial / > intro kind of stuff. > > Adam -- Rolf Schaufelberger
Re: mod_perl survey results
On Mon, Nov 10, 2008 at 11:45 AM, Issac Goldstand <[EMAIL PROTECTED]> wrote: > However, it's not necessarily better if your memory consumption goes > mostly to run-time data which can't be pre-generated (in which case > worker is better for the reasons listed below, since there's no COW benefit) That's true if you're talking about data that you load into an explicitly shared variable, but I have to say I have never seen that scenario in real life. For almost everyone, the memory used by lexical variables and code is the vast majority. Every now and then someone comes along claiming that databases are too slow for them and wanting to share a massive structure between apache children. Those people should try threads (and probably compare to prefork + BerkeleyDB). > The reason that so many people like worker, I think, is because mp2 was > designed so you can have workers shift from thread to thread, and be > able to serve both mp and static content from the same Apache without > losing performance, since not every child needs it's own "private" > interpreter. This out-performs preform in almost every way... except > memory sharing. Well, I'd say it outperforms prefork in one way, which is that you don't need a front-end proxy server and thus avoid that overhead. It would be great to see some benchmark numbers on this. Unfortunately, that gain is pretty much swamped by the reduced number of back-ends you can run with threads due to the additional memory required. - Perrin
Re: mod_perl survey results
Adam Prime wrote: André Warnier wrote: Maybe this is the time to ask. I am using Linux Debian, and getting Apache 2, perl and mod_perl 2 from there (apt-get). I have never been quite sure which mpm the packager decided to configure, as the apache2.conf contains parameters for prefork, pthread and perchild. So, a) which is the best way to find out ? b) if it happened to be "worker" or something, could I just change that to "prefork", or is there more to it ? (Also so far, even if it is using a threaded mpm, it does not seem to have any deleterious effect on my systems, which are pretty stable). Thanks ./httpd -V Server version: Apache/2.0.54 Server built: Sep 25 2005 00:31:31 Server's Module Magic Number: 20020903:9 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" ... The -D APACHE_MPM_DIR tells you which MPM your apache is using. In order to change MPM's you need to recompile apache, and quite possibly mod_perl as well, i have no idea how you'd accomplish that on debian using apt. Thanks. In case anybody is interested, here it is thus under Debian Etch : uname -a : Linux arthur 2.6.18-6-686 #1 SMP Thu May 8 07:34:27 UTC 2008 i686 GNU/Linux [EMAIL PROTECTED]:~# /usr/sbin/apache2ctl -V Server version: Apache/2.2.3 Server built: Jan 27 2008 18:13:21 Server's Module Magic Number: 20051115:3 Server loaded: APR 1.2.7, APR-Util 1.2.7 Compiled using: APR 1.2.7, APR-Util 1.2.7 Architecture: 32-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT="" -D SUEXEC_BIN="/usr/lib/apache2/suexec" -D DEFAULT_PIDLOG="/var/run/apache2.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="/var/run/apache2/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="/etc/apache2/mime.types" -D SERVER_CONFIG_FILE="/etc/apache2/apache2.conf" [EMAIL PROTECTED]:~# prefork thus. I'll re-read the previous posts now, about what's better, faster, sexier, etc.. André
Re: mod_perl survey results
On Mon 10 Nov 2008, Steven Siebert wrote: > More memory but potentially faster, correct? Since we don't have to > spawn as many processes to accommodate a load? Perl is a real memory hog. Byte-compiled code can become quite big. Multiply that with the number of perl interpreters running and you'll get huge numbers. With the prefork MPM we use the "load all modules you need at startup" mantra. This way the operating system comes to rescue with copy-on-write. The byte-compiled code is almost read-only after it is compiled. If it is compiled by the perl interpreter in the parent apache all that memory becomes shared memory. With a threaded MPM the situation is different. Here at startup we have one perl interpreter that loads all the modules. Then AFTER the child is forked it creates as many as configured additional interpreters. Each of those is a copy of the master interpreter. But now all the memory that holds the byte-compiled code is allocated again for each interpreter and almost nothing is shared by copy-on-write. So the creation of a new perl interpreter is really expensive. Although there is one sane usage of modperl with a threaded MPM, I believe. If your only modperl usage is to configure the request at runtime, do authentication etc you need the interpreter only for a small part of the request cycle. So you can configure say 3 interpreters to handle 250 or so threads. But for that to become usable we need a better modperl and perhaps better MPMs (event based). Torsten -- Need professional mod_perl support? Just hire me: [EMAIL PROTECTED]
Re: mod_perl survey results
I'm relatively new to mod_perl - moving to a new job who's application is solely written in it. This is a return to Perl for me, having worked in PHP, Java, and .NET since Perl 4. As I'm learning to love mod_perl and Perl in general, perhaps it's a good time for me to contribute back by writing perl/mod_perl blogs and tutorials to help others easing in from other languages (written with a set of assumptions). I've seen the "to-do" list, if you will, on the mod_perl Advocacy page (http://perl.apache.org/docs/general/advocacy/advocacy.html) but not sure how dated this is or what is the best to tackle. Let me know how to get involved - it is my job security after all =). Seriously, though, the flexibility of mod_perl is just not available in many of the other languages and I think it's "don't know what you don't know" sort of thing...so much work is done in the application code when it could be solved with a few lines using mod_perl at the httpd abstract layer. I have a blog site but if perl.apache.org desires host tutorials and blogs, so much the better (better discoverability). I've also noticed the mod_perl advocacy mailing list is all but dead. Perhaps this is the best channel to bring these issues up? Regards, Steve On Mon, Nov 10, 2008 at 8:59 AM, Adam Prime <[EMAIL PROTECTED]> wrote: > André Warnier wrote: >> >> The responses there are indeed a bit scary. It feels like we're a dying >> breed. >> I believe this is to a large extent a "marketing issue" for perl in >> general, and mod_perl by extension, with regard to the younger programmers >> generation. At least in various European countries I know, perl is not >> really being taught in programming schools as a "serious" programming >> language for applications. These young people have all heard the name, but >> seem to consider it as a powerful but somewhat messy scripting language to >> create system administration scripts. >> I am personally doing my best to introduce these newbies to the beauties >> of perl and mod_perl, but it feels rather lonely sometimes. >> Java and PHP seem definitely more popular, or better-known. > > I agree that this does echo perl's problems in general, but mod_perl has a > long history of not really being very good at marketing itself. I know > Perrin and some other people did try at the launch of mod_perl2, but that > effort (and the associated mailing list) has long since dried up. > >> - A surprising number of people are running mod_perl under the worker MPM. >> What is so surprising about this ? (genuine curious question) > > It's surprising to me, and probably to Torsten, because the perceived common > wisdom is to run prefork, because worker may or may not be as well tested, > and has all the bonus issues related to thread-safeness. > - the documentation could use some work. Specifically more tutorial / intro kind of stuff. >> >> Agreed. There is a definite need also for something like a new mod_perl >> Guide and Cookbook all-in-one, updated for mod_perl 2 and with a section >> about the framework/template systems mentioned above. Written in a style >> meant to show that these are not old-fashioned technologies only practised >> by oldies like me (us?). >> What I mean is that to cover all one needs to know to create some serious >> web applications in Java, you'd need at least 6 thick volumes, while for >> Perl 800-1000 pages would be more than enough. >> O'Reilly, where are you ? > > Honestly, I think this stuff is currently better handled by the community. > As such, i'm going to take a stab at writing some very basic intro / > tutorial kind of documentation to be added to perl.apache.org. When i > started with mod_perl 1, the Guide on thought the "guide" perl.apache.org > was amazing, but it seems to me that mod_perl 2 doesn't have that in the > same way. Much of the content has been ported over to the 2.0 section, but > there are many pages that haven't been updated from the 1.0 tree at all. > > Adam >
Re: Substituting URLs in PerlOutputFilterHandler
On Mon 10 Nov 2008, Puneet Lakhina wrote: > essentially im trying to modify > tags in the outgoing HTML pages. > Now I am trying to do this using PerlOutputFilterHandler. I have the > following questions: > a) Is this the right filter to use for an application like this? yes > b) As per my understanding my hander can be invoked multiple times > based on the no. of buckets. Is this correct? yes > If yes, then how should > I handle the situation where a part of the tag like say ' comes in one bucket and '="">' comes in another. The basic idea is to carry around the tail of the current buffer, the 'http://perl.apache.org/docs/2.0/user/handlers/filters.html#Stream_oriented_Output_Filters shows the technique. The OutputFilter routine in Apache2::ClickPath (on CPAN) is another example. Torsten -- Need professional mod_perl support? Just hire me: [EMAIL PROTECTED]
Re: mod_perl survey results
On Mon, 10 Nov 2008, Adam Prime wrote: André Warnier wrote: Maybe this is the time to ask. I am using Linux Debian, and getting Apache 2, perl and mod_perl 2 from there (apt-get). I have never been quite sure which mpm the packager decided to configure, as the apache2.conf contains parameters for prefork, pthread and perchild. ./httpd -V Server version: Apache/2.0.54 Server built: Sep 25 2005 00:31:31 Server's Module Magic Number: 20020903:9 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" ... The -D APACHE_MPM_DIR tells you which MPM your apache is using. In order to change MPM's you need to recompile apache, and quite possibly mod_perl as well, i have no idea how you'd accomplish that on debian using apt. The Debian distribution packages the different MPMs into different binary packages, which are labelled as alternatives to each other, so you load apache2-common and the MPM of your choice. Each MPM package contains a suitably compiled binary. If you don't choose explicitly, apt-get picks one (prefork, I think) for you. However, and it's an important one, the Debian packaging system also contains expectations from the maintainer(s) about which MPMs are required or recommended for mod_perl2, mod_php5, and so forth, and will not let you choose an MPM which those extra packages do not allow. If you want a free choice of configuration, e.g. to run mod_perl2 threaded, you may have to rebuild the packages yourself or build from source. Cheers, John
general performance issues
Hi. This is not really an on-topic question, and is more of a general one. But I figure that, for this type of "general", the combination of skills of the people on this list might be just right to provide some pointers. If it's too off-topic nevertheless, just send me packing, I won't insist. The "top" snapshot below shows one of our old clunkers, doing essentially nothing for now. It's an average desktop PC from a few years back, running Linux Debian Etch, with a venerable Pentium II as processor, 512 Mb Ram and your average PC disks from back then. It is so old that there is in fact a problem still finding the memory cards that fit in it. Yet most of the time it faithfully does its job, which is to be a development and test machine for a small team of programmers. But sometimes it doesn't, and becomes rather slow for a while. The programs that run on it are fairly typical of our production machines (which are much newer/bigger/better), which is why I ask. I figure that considering the respectable age of this system and its limited everything, anything that we would do to improve its generic performance would be all the more effective if applied to the production servers, right ? or wrong ? in a generic way I mean. Also, I want to add that we do not really have a problem yet, I am just trying to gather some general information and general impressions,maybe collect some tricks or tools for the future. We can easily get another more recent PC to replace that one. But maybe then it would be harder to put it under stress and see where there is a bottleneck. We thus run on these machines : Apache 2.x with mod_perl 2.x, Tomcat 5.5, and mod_jk 1.2.x to connect them. Under Tomcat run a couple of very small servlets, and one that seems to be really huge compared to the others. Under Apache directly, we have a series of application components running as mod_perl modules or as cgi-bin scripts. We always access our web applications through Apache. Apart from Tomcat and Apache-based stuff, there are also a few other "daemons" running which you can see. A couple of them (the next 2 after Tomcat) are java daemons, and they process (and parse) XML files all day. A couple of stand-alone perl processes are also daemons, and also process XML data. The two "star" processes at the bottom are parts of a special database system, written in C. The one "python" process running there is "denyhosts". This "top" display is sorted by "memory" (one of the options of memory in top, "n", I'm not quite sure what it corresponds to). The first thing that strikes me, is the huge memory allocated to Tomcat and the other Java processes. I wonder if this unavoidable, or if it is just misconfiguration on my part. The "huge Tomcat application" is unfortunately one that we just buy, we can't peek in the code to see what's going on there. We just know it is (also) processing some large quantity of XML data, mostly when it starts up. That almost paralyses our server for 10 minutes or so when we restart Tomcat. The other question is, does the memory shown as used by the Apache processes seem normal/abnormal to anyone ? This being a prefork Apache, if it seems abnormal, what kind of thing should I look at ? Or is it so normal that I should not even spend time on it ? (I already load a fair number of modules in a startup script, but maybe I should load even more of them there, if there is no penalty). Thanks for any reactions, even if it is to tell me that I don't know what I'm talking about or that this isn't the right place. But then, be as kind maybe as pointing me to the right place. Sample "top" : PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 6226 tomcat55 25 0 506m 188m 10m S 0.0 37.3 127:01.74 java 5937 root 15 0 267m 28m 8056 S 0.0 5.6 24:20.96 java 8613 root 24 0 260m 15m 9332 S 0.0 3.1 0:02.16 java 8640 root 15 0 29560 15m 5984 S 0.0 3.0 0:02.10 apache2 8632 efs 15 0 16964 12m 1968 S 0.0 2.6 0:06.96 MiraLoader.pl 8665 www-data 15 0 29692 12m 3016 S 0.0 2.4 0:08.82 apache2 8662 www-data 15 0 29692 12m 3016 S 0.0 2.4 0:08.74 apache2 12414 www-data 15 0 29560 10m 1624 S 0.0 2.2 0:08.32 apache2 12415 www-data 15 0 29560 10m 1624 S 0.0 2.2 0:08.33 apache2 18880 www-data 15 0 29560 10m 1624 S 0.0 2.2 0:04.84 apache2 18881 www-data 18 0 29560 10m 1624 S 0.0 2.2 0:04.37 apache2 18882 www-data 15 0 29560 10m 1624 S 0.0 2.2 0:04.55 apache2 8666 efs 15 0 13532 9724 2000 S 0.0 1.9 0:02.40 MiraFiler.pl 21408 root 18 0 9940 3884 1376 S 0.0 0.8 32:10.91 python 24934 efs 17 0 11708 2812 2172 S 0.0 0.5 0:00.06 smbd 23831 efs 18 0 14548 2680 1724 S 0.0 0.5 0:03.35 MiraASci.pl 23848 efs 15 0 11696 2568 1708 S 0.0 0.5 0:03.03 ifsser.pl 24752 root 15 0 7804 2324 1836 S 0.0 0.4 0:00.12 sshd
[mp2.0.4] t/hooks/authen_basic (Wstat: 0 Tests: 4 Failed: 1)
Hi, I have been trying to install mp2.0.4. In addition to having problems with authen_basic, I am also getting a test fail for t/hooks/authz as well. My perl Makefile command is as follows: perl Makefile.PL MP_APXS=/home/Intranet/ssiweb/apache/bin/apxs Here are the relevant contents from the log file: [Mon Nov 10 13:00:38 2008] [notice] Digest: generating secret for digest authentication ... [Mon Nov 10 13:00:38 2008] [notice] Digest: done [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 13:00:38 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for
Re: [mp2.0.4] t/hooks/authen_basic (Wstat: 0 Tests: 4 Failed: 1)
Chen, Peter wrote: Hi, I have been trying to install mp2.0.4. In addition to having problems with authen_basic, I am also getting a test fail for t/hooks/authz as well. My perl Makefile command is as follows: *perl Makefile.PL MP_APXS=/home/Intranet/ssiweb/apache/bin/apxs* Here are the relevant contents from the log file: END in modperl_extra.pl, pid=19963 END in modperl_extra.pl, pid=19962 END in modperl_extra.pl, pid=19979 [Mon Nov 10 13:00:43 2008] [info] removed PID file /home/src/perl_modules/mod_perl-2.0.4/t/logs/httpd.pid (pid=19955) [Mon Nov 10 13:00:43 2008] [notice] caught SIGTERM, shutting down END in modperl_extra.pl, pid=19955 What's in modperl_extra.pl? You didn't really describe what's you're seeing, so i'm assuming that apache isn't starting up correctly, and that that's what you're seeing in the error_log with the LogLevel set to debug.
Re: general performance issues
André Warnier wrote: If it's too off-topic nevertheless, just send me packing, I won't insist. I might be alone in this but I think apache memory use is something all heavy mod_perl users have to get to grips with, so I mentally s/java|tomcat/mod_perl/g'd and read your very long email But sometimes it doesn't, and becomes rather slow for a while. Find out if it's *actual* slowness or just HTTP requests being queued up because none of the apache children are free to service the request. anything that we would do to improve its generic performance would be all the more effective if applied to the production servers, right ? or wrong ? in a generic way I mean. I agree but with one caveat - memory is very cheap at the moment. Strike a good balance between spending hours trimming the memory footprint of your app and buying more RAM. The first thing that strikes me, is the huge memory allocated to Tomcat and the other Java processes. I wonder if this unavoidable, or if it is just misconfiguration on my part. The "huge Tomcat application" is unfortunately one that we just buy, we can't peek in the code to see what's going on there. We just know it is (also) processing some large quantity of XML data, mostly when it starts up. That almost paralyses our server for 10 minutes or so when we restart Tomcat. Tongue in cheek, thats what you get for not rewriting it in perl ;) Seriously though, in your own apps make sure you're not loading large XML files fully into RAM before parsing them. Use a SAX or similar parser to treat large XML files like a stream. The other question is, does the memory shown as used by the Apache processes seem normal/abnormal to anyone ? This being a prefork Apache, if it seems abnormal, what kind of thing should I look at ? Or is it so normal that I should not even spend time on it ? Those are very lean looking apache's by my own experience, I don't think you'll do much better. hope that's useful, John
Re: [mp2.0.4] t/hooks/authen_basic (Wstat: 0 Tests: 4 Failed: 1)
Chen, Peter wrote: Apache isn't starting up correctly? I already have the apache server running. Will this affect the configuration? When I type the command "ps -eaf | grep apache", it seems to indicate that apache is running. Please CC the list on your replies, it has much more wisdom than I do. I'm trying to understand what you're asking for help with. Your subject is about a build test failing, but then you included a wall of error_log output, which doesn't really seem to be related, but does seem to indicate that you've got mod_perl 2.0.4 installed and running. mod_perl 2 has frequently had it's tests start failing when new versions of httpd have come out and changed things around a bit, those tests have frequently resided in the auth subsystem, but generally have been problems with the test, not with mod_perl or apache. I have no idea if that is the case in this particular situation though, i personally haven't built 2.0.4 against 2.2.10 on any platform, never mind solaris. Personally, i think that when this occurs, a new version of mod_perl should be pushed out that corrects the problem (even if it doesn't correct anything else), but I'm not on the dev team ;) So I guess my question is, what's your question? Adam
Re: [mp2.0.4] t/hooks/authen_basic (Wstat: 0 Tests: 4 Failed: 1)
Adam Prime wrote: Personally, i think that when this occurs, a new version of mod_perl should be pushed out that corrects the problem (even if it doesn't correct anything else), but I'm not on the dev team ;) I think that is th general idea. As someone on httpd I wasn't aware of any land breaking changes in 2.2.10 vs 2.2.9. -- Philip M. Gollucci ([EMAIL PROTECTED]) c: 703.336.9354 Consultant - P6M7G8 Inc. http://p6m7g8.net Senior System Admin - RideCharge, Inc. http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
RE: [mp2.0.4] t/hooks/authen_basic (Wstat: 0 Tests: 4 Failed: 1)
Hmm, I guess my question is what could be causing Test 4 of t/hooks/authen_basic.t and Test 4 of t/hooks/authz.t to fail? Do I need to make Apache-Test ModPerl-Registry prior to making mod-perl? -Original Message- From: Adam Prime [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2008 2:49 PM To: Chen, Peter; mod_perl list Subject: Re: [mp2.0.4] t/hooks/authen_basic (Wstat: 0 Tests: 4 Failed: 1) Chen, Peter wrote: > Apache isn't starting up correctly? I already have the apache server > running. Will this affect the configuration? When I type the command "ps > -eaf | grep apache", it seems to indicate that apache is running. > Please CC the list on your replies, it has much more wisdom than I do. I'm trying to understand what you're asking for help with. Your subject is about a build test failing, but then you included a wall of error_log output, which doesn't really seem to be related, but does seem to indicate that you've got mod_perl 2.0.4 installed and running. mod_perl 2 has frequently had it's tests start failing when new versions of httpd have come out and changed things around a bit, those tests have frequently resided in the auth subsystem, but generally have been problems with the test, not with mod_perl or apache. I have no idea if that is the case in this particular situation though, i personally haven't built 2.0.4 against 2.2.10 on any platform, never mind solaris. Personally, i think that when this occurs, a new version of mod_perl should be pushed out that corrects the problem (even if it doesn't correct anything else), but I'm not on the dev team ;) So I guess my question is, what's your question? Adam -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- This message is for the named person's use only. This communication is for informational purposes only and has been obtained from sources believed to be reliable, but it is not necessarily complete and its accuracy cannot be guaranteed. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. Moreover, this material should not be construed to contain any recommendation regarding, or opinion concerning, any security. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Securities products and services provided to Canadian investors are offered by ITG Canada Corp. (member CIPF and IDA), an affiliate of Investment Technology Group, Inc. ITG Inc. and/or its affiliates reserves the right to monitor and archive all electronic communications through its network. ITG Inc. Member FINRA, SIPC -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
RE: [mp2.0.4] t/hooks/authen_basic (Wstat: 0 Tests: 4 Failed: 1)
Ok, I found modperl_extra.pl. It's located in t/conf/modperl_extra.pl -Original Message- From: Adam Prime [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2008 2:49 PM To: Chen, Peter; mod_perl list Subject: Re: [mp2.0.4] t/hooks/authen_basic (Wstat: 0 Tests: 4 Failed: 1) Chen, Peter wrote: > Apache isn't starting up correctly? I already have the apache server > running. Will this affect the configuration? When I type the command "ps > -eaf | grep apache", it seems to indicate that apache is running. > Please CC the list on your replies, it has much more wisdom than I do. I'm trying to understand what you're asking for help with. Your subject is about a build test failing, but then you included a wall of error_log output, which doesn't really seem to be related, but does seem to indicate that you've got mod_perl 2.0.4 installed and running. mod_perl 2 has frequently had it's tests start failing when new versions of httpd have come out and changed things around a bit, those tests have frequently resided in the auth subsystem, but generally have been problems with the test, not with mod_perl or apache. I have no idea if that is the case in this particular situation though, i personally haven't built 2.0.4 against 2.2.10 on any platform, never mind solaris. Personally, i think that when this occurs, a new version of mod_perl should be pushed out that corrects the problem (even if it doesn't correct anything else), but I'm not on the dev team ;) So I guess my question is, what's your question? Adam -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- This message is for the named person's use only. This communication is for informational purposes only and has been obtained from sources believed to be reliable, but it is not necessarily complete and its accuracy cannot be guaranteed. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. Moreover, this material should not be construed to contain any recommendation regarding, or opinion concerning, any security. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Securities products and services provided to Canadian investors are offered by ITG Canada Corp. (member CIPF and IDA), an affiliate of Investment Technology Group, Inc. ITG Inc. and/or its affiliates reserves the right to monitor and archive all electronic communications through its network. ITG Inc. Member FINRA, SIPC -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Re: [mp2.0.4] t/hooks/authen_basic (Wstat: 0 Tests: 4 Failed: 1)
On Mon, Nov 10, 2008 at 1:13 PM, Chen, Peter <[EMAIL PROTECTED]> wrote: > I have been trying to install mp2.0.4. In addition to having problems with > authen_basic, I am also getting a test fail for t/hooks/authz as well. Can you post the output of this command? ./t/TEST -verbose t/hooks/authz.t
RE: [mp2.0.4] t/hooks/authen_basic (Wstat: 0 Tests: 4 Failed: 1)
Here are the results from the terminal: [warning] Skipping 'set unlimited ulimit for coredumps', since we are running as a non-root user on Solaris /home/Intranet/ssiweb/apache/bin/httpd -d /home/src/perl_modules/mod_perl-2.0.4/t -f /home/src/perl_modules/mod_perl-2.0.4/t/conf/httpd.conf -D APACHE2 using Apache/2.2.10 (prefork MPM) waiting 120 seconds for server to start: ...[Mon Nov 10 15:44:26 2008] [info] 6 Apache2:: modules loaded [Mon Nov 10 15:44:26 2008] [info] 0 APR:: modules loaded [Mon Nov 10 15:44:26 2008] [info] base server + 29 vhosts ready to run tests waiting 120 seconds for server to start: ok (waited 15 secs) server localhost:8529 started server localhost:8530 listening (filter_out_apache) server localhost:8531 listening (perlsections) server localhost:8532 listening (inherit) server localhost:8533 listening (TestModperl::merge) server localhost:8534 listening (TestModperl::perl_options) server localhost:8535 listening (TestModperl::perl_options2) server localhost:8536 listening (TestModperl::setupenv) server localhost:8537 listening (TestModules::proxy) server localhost:8538 listening (TestUser::rewrite) server localhost:8539 listening (TestVhost::config) server localhost:8540 listening (TestVhost::log) server localhost:8541 listening (TestProtocol::echo_bbs) server localhost:8542 listening (TestProtocol::echo_bbs2) server localhost:8543 listening (TestProtocol::echo_block) server localhost:8544 listening (TestProtocol::echo_filter) server localhost:8545 listening (TestProtocol::echo_nonblock) server localhost:8546 listening (TestProtocol::echo_timeout) server localhost:8547 listening (TestProtocol::pseudo_http) server localhost:8548 listening (TestPreConnection::note) server localhost:8549 listening (TestHooks::hookrun) server localhost:8550 listening (TestHooks::init) server localhost:8551 listening (TestHooks::stacked_handlers2) server localhost:8552 listening (TestHooks::startup) server localhost:8553 listening (TestHooks::trans) server localhost:8554 listening (TestFilter::both_str_con_add) server localhost:8555 listening (TestFilter::in_bbs_inject_header) server localhost:8556 listening (TestFilter::in_bbs_msg) server localhost:8557 listening (TestFilter::in_str_msg) server localhost:8558 listening (TestDirective::perlmodule) server localhost:8559 listening (TestDirective::perlrequire) server localhost:8560 listening (TestAPI::add_config) server localhost:8561 listening (TestDirective::perlloadmodule3) server localhost:8562 listening (TestDirective::perlloadmodule4) server localhost:8563 listening (TestDirective::perlloadmodule5) server localhost:8564 listening (TestDirective::perlloadmodule6) server localhost:8565 listening (TestHooks::push_handlers_anon) t/hooks/authz 1..4 # Running under perl version 5.008008 for solaris # Current time local: Mon Nov 10 15:44:41 2008 # Current time GMT: Mon Nov 10 23:44:41 2008 # Using Test.pm version 1.25 # Using Apache/Test.pm version 1.31 ok 1 ok 2 ok 3 not ok 4 # Failed test 4 in t/hooks/authz.t at line 19 Failed 1/4 subtests Test Summary Report --- t/hooks/authz (Wstat: 0 Tests: 4 Failed: 1) Failed test: 4 Files=1, Tests=4, 4 wallclock secs ( 0.13 usr 0.07 sys + 2.10 cusr 0.59 csys = 2.89 CPU) Result: FAIL Failed 1/1 test programs. 1/4 subtests failed. [warning] server localhost:8529 shutdown [ error] error running tests (please examine t/logs/error_log) And here is the ERROR_LOG [Mon Nov 10 15:44:31 2008] [info] mod_unique_id: using ip addr 172.17.1.105 END in modperl_extra.pl, pid=20659 [Mon Nov 10 15:44:39 2008] [info] mod_unique_id: using ip addr 172.17.1.105 [Mon Nov 10 15:44:40 2008] [notice] Digest: generating secret for digest authentication ... [Mon Nov 10 15:44:40 2008] [notice] Digest: done [Mon Nov 10 15:44:40 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 15:44:40 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 15:44:40 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 15:44:40 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 15:44:40 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 15:44:40 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 15:44:40 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 15:44:40 2008] [debug] util_ldap.c(1977): LDAP merging Shared Cache conf: shm=0x12fdd0 rmm=0x12fe00 for VHOST: localhost [Mon Nov 10 15:44:40 2008] [debug] util_ldap.c(1977): LDAP merging S
Re: [mp2.0.4] t/hooks/authen_basic (Wstat: 0 Tests: 4 Failed: 1)
I just tried this test with 2.0.4 and 2.2.10 (default configuration)
and it passed. Might be the way your have apache configured, can you
post the output of 'httpd -l'?
You could modify t/hooks/authz.t to dump out the response code -
here's how I did it:
19 ok ! GET_OK $location, username => 'jobbob', password => 'whatever';
20 $rc = GET $location, username => 'jabbob', password => 'whatever';
21 use Data::Dumper;
22 warn("rc was " . Dumper($rc));
If you can make that modification post the results back here.
On Mon, Nov 10, 2008 at 3:48 PM, Chen, Peter <[EMAIL PROTECTED]> wrote:
> Here are the results from the terminal:
>
> [warning] Skipping 'set unlimited ulimit for coredumps', since we are
> running as a non-root user on Solaris
> /home/Intranet/ssiweb/apache/bin/httpd -d
> /home/src/perl_modules/mod_perl-2.0.4/t -f
> /home/src/perl_modules/mod_perl-2.0.4/t/conf/httpd.conf -D APACHE2
> using Apache/2.2.10 (prefork MPM)
>
> waiting 120 seconds for server to start: ...[Mon Nov 10 15:44:26 2008]
> [info] 6 Apache2:: modules loaded
> [Mon Nov 10 15:44:26 2008] [info] 0 APR:: modules loaded
> [Mon Nov 10 15:44:26 2008] [info] base server + 29 vhosts ready to run
> tests
>
RE: [mp2.0.4] t/hooks/authen_basic (Wstat: 0 Tests: 4 Failed: 1)
Results of httpd -l:
Compiled in modules:
core.c
prefork.c
http_core.c
mod_so.c
--
and the results after adding the lines:
[warning] Skipping 'set unlimited ulimit for coredumps', since we are
running as a n
on-root user on Solaris
/home/Intranet/ssiweb/apache/bin/httpd -d
/home/src/perl_modules/mod_perl-2.0.4/t -
f /home/src/perl_modules/mod_perl-2.0.4/t/conf/httpd.conf -D APACHE2
using Apache/2.2.10 (prefork MPM)
waiting 120 seconds for server to start: ..[Mon Nov 10 16:31:43 2008]
[info] 6 Apach
e2:: modules loaded
[Mon Nov 10 16:31:43 2008] [info] 0 APR:: modules loaded
[Mon Nov 10 16:31:43 2008] [info] base server + 29 vhosts ready to run
tests
.
waiting 120 seconds for server to start: ok (waited 15 secs)
server localhost:8529 started
server localhost:8530 listening (filter_out_apache)
server localhost:8531 listening (perlsections)
server localhost:8532 listening (inherit)
server localhost:8533 listening (TestModperl::merge)
server localhost:8534 listening (TestModperl::perl_options)
server localhost:8535 listening (TestModperl::perl_options2)
server localhost:8536 listening (TestModperl::setupenv)
server localhost:8537 listening (TestModules::proxy)
server localhost:8538 listening (TestUser::rewrite)
server localhost:8539 listening (TestVhost::config)
server localhost:8540 listening (TestVhost::log)
server localhost:8541 listening (TestProtocol::echo_bbs)
server localhost:8542 listening (TestProtocol::echo_bbs2)
server localhost:8543 listening (TestProtocol::echo_block)
server localhost:8544 listening (TestProtocol::echo_filter)
server localhost:8545 listening (TestProtocol::echo_nonblock)
server localhost:8546 listening (TestProtocol::echo_timeout)
server localhost:8547 listening (TestProtocol::pseudo_http)
server localhost:8548 listening (TestPreConnection::note)
server localhost:8549 listening (TestHooks::hookrun)
server localhost:8550 listening (TestHooks::init)
server localhost:8551 listening (TestHooks::stacked_handlers2)
server localhost:8552 listening (TestHooks::startup)
server localhost:8553 listening (TestHooks::trans)
server localhost:8554 listening (TestFilter::both_str_con_add)
server localhost:8555 listening (TestFilter::in_bbs_inject_header)
server localhost:8556 listening (TestFilter::in_bbs_msg)
server localhost:8557 listening (TestFilter::in_str_msg)
server localhost:8558 listening (TestDirective::perlmodule)
server localhost:8559 listening (TestDirective::perlrequire)
server localhost:8560 listening (TestAPI::add_config)
server localhost:8561 listening (TestDirective::perlloadmodule3)
server localhost:8562 listening (TestDirective::perlloadmodule4)
server localhost:8563 listening (TestDirective::perlloadmodule5)
server localhost:8564 listening (TestDirective::perlloadmodule6)
server localhost:8565 listening (TestHooks::push_handlers_anon)
t/hooks/authz
1..4
# Running under perl version 5.008008 for solaris
# Current time local: Mon Nov 10 16:31:58 2008
# Current time GMT: Tue Nov 11 00:31:58 2008
# Using Test.pm version 1.25
# Using Apache/Test.pm version 1.31
ok 1
ok 2
ok 3
not ok 4
# Failed test 4 in t/hooks/authz.t at line 19
rc was $VAR1 = bless( {
'_protocol' => 'HTTP/1.1',
'_content' => '1..1
# Running under perl version 5.008008 for solaris
# Current time local: Mon Nov 10 16:31:51 2008
# Current time GMT: Tue Nov 11 00:31:51 2008
# Using Test.pm version 1.25
# Using Apache/Test.pm version 1.31
ok 1
',
'_rc' => '200',
'_headers' => bless( {
'client-date' => 'Tue, 11 Nov
2008 00:32:02
GMT',
'content-type' => 'text/plain',
'connection' => 'close',
'date' => 'Tue, 11 Nov 2008
00:32:02 GMT',
'client-peer' =>
'127.0.0.1:8529',
'server' => 'Apache/2.2.10
(Unix) world domi
nation series/2.0 DAV/2 PHP/5.2.6 mod_perl/2.0.4 Perl/v5.8.8'
}, 'HTTP::Headers' ),
'_msg' => 'OK',
'handlers' => {
'response_data' => [
sub { "DUMMY" }
]
},
'_request' => bless( {
'_content' => '',
'_uri' => bless( do{\(my $o =
'http://localh
ost:8529/TestHooks__authz')}, 'URI::http' ),
'_headers' => bless( {
'user-agent' => 'libw
ww-perl/5.817',
'authorization' => 'B
asic ZG91Z206Zm9v'
},
'HTTP::Headers' ),
'_method' => 'GET'
Re: [mp2.0.4] t/hooks/authen_basic (Wstat: 0 Tests: 4 Failed: 1)
On Mon, Nov 10, 2008 at 4:33 PM, Chen, Peter <[EMAIL PROTECTED]> wrote:
> Results of httpd -l:
>
> Compiled in modules:
> core.c
> prefork.c
> http_core.c
> mod_so.c
Ok, so everything is loaded as shared objects.
> not ok 4
> # Failed test 4 in t/hooks/authz.t at line 19
> rc was $VAR1 = bless( {
> '_protocol' => 'HTTP/1.1',
> '_content' => '1..1
> # Running under perl version 5.008008 for solaris
> # Current time local: Mon Nov 10 16:31:51 2008
> # Current time GMT: Tue Nov 11 00:31:51 2008
> # Using Test.pm version 1.25
> # Using Apache/Test.pm version 1.31
> ok 1
> ',
> '_rc' => '200',
And basic auth is failing. If you don't have any 'require user'
directives in your httpd.conf, you shouldn't have anything to worry
about. Interesting test failure though, I wonder if there is a
problem with basic auth in Apache 2.2.10.
If you do need basic auth I would suggest trying apache 2.2.9 or 2.2.8.
RE: [mp2.0.4] t/hooks/authen_basic (Wstat: 0 Tests: 4 Failed: 1)
Thanks, Fred.
So if I need basic auth, I should go back to Apache2.2.8 or 2.2.9?
And if I do not need basic auth, then what should I do?
-Original Message-
From: Fred Moyer [mailto:[EMAIL PROTECTED]
Sent: Monday, November 10, 2008 4:47 PM
To: Chen, Peter
Cc: modperl@perl.apache.org
Subject: Re: [mp2.0.4] t/hooks/authen_basic (Wstat: 0 Tests: 4 Failed:
1)
On Mon, Nov 10, 2008 at 4:33 PM, Chen, Peter <[EMAIL PROTECTED]> wrote:
> Results of httpd -l:
>
> Compiled in modules:
> core.c
> prefork.c
> http_core.c
> mod_so.c
Ok, so everything is loaded as shared objects.
> not ok 4
> # Failed test 4 in t/hooks/authz.t at line 19
> rc was $VAR1 = bless( {
> '_protocol' => 'HTTP/1.1',
> '_content' => '1..1
> # Running under perl version 5.008008 for solaris
> # Current time local: Mon Nov 10 16:31:51 2008
> # Current time GMT: Tue Nov 11 00:31:51 2008
> # Using Test.pm version 1.25
> # Using Apache/Test.pm version 1.31
> ok 1
> ',
> '_rc' => '200',
And basic auth is failing. If you don't have any 'require user'
directives in your httpd.conf, you shouldn't have anything to worry
about. Interesting test failure though, I wonder if there is a
problem with basic auth in Apache 2.2.10.
If you do need basic auth I would suggest trying apache 2.2.9 or 2.2.8.
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
This message is for the named person's use only. This communication is for
informational purposes only and has been obtained from sources believed to
be reliable, but it is not necessarily complete and its accuracy cannot be
guaranteed. It is not intended as an offer or solicitation for the purchase
or sale of any financial instrument or as an official confirmation of any
transaction. Moreover, this material should not be construed to contain any
recommendation regarding, or opinion concerning, any security. It may
contain confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender. You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. Any views expressed in this message are those of the individual
sender, except where the message states otherwise and the sender is
authorized to state them to be the views of any such entity.
Securities products and services provided to Canadian investors are offered
by ITG Canada Corp. (member CIPF and IDA), an affiliate of Investment
Technology Group, Inc.
ITG Inc. and/or its affiliates reserves the right to monitor and archive
all electronic communications through its network.
ITG Inc. Member FINRA, SIPC
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Re: [mp2.0.4] t/hooks/authen_basic (Wstat: 0 Tests: 4 Failed: 1)
On Mon, Nov 10, 2008 at 5:09 PM, Chen, Peter <[EMAIL PROTECTED]> wrote: > Thanks, Fred. > > So if I need basic auth, I should go back to Apache2.2.8 or 2.2.9? Well you should run the tests with mod_perl also and see if they still fail when built against those versions of mod_perl. But it could be that basic auth is working and the test is just failing for some reason :) There is no substitute for setting up an actual handler and testing it from the browser also, in case this is a solaris specific bug in the testing suite. > And if I do not need basic auth, then what should I do? Go forth and code! :)
Re: mod_perl survey results
Adam Prime wrote: > The results of the mod_perl survey that Fred Moyer and I conducted can > be found at the following link: Interesting list. Any chance the workshop will come to Singapore? :) I am strangely excited by the potential of filters. mod_perl feels like a generic tool that can do more than just apps (as evidenced by the fact that not PerlResponseHandler is only used by 68.8% of apps). Yet after all these years I'm still not scratching beyond the surface of its capabilities. But then again, I'm but a dying breed in my country...
