FYI Small hints for modules using directives
If anyone out there's building modules with directives you'll know
that its a tricky business. I ran across two problems and related
solutions. (Thanks for nudging me along for #1 Geoff - but #2 I solved
all by my lonesome!)
FIRST HINT - Modules compirised of several files and make Apache
Directives:
- Apache::ExtUtils is a bit more fussy than the regular ExtUtils
about paths for loading subfiles of a package.
- Can't load main module to resolve function prototypes at
perl Makefile.PL
I found I had to take the following approach. Imagine that I have a
sub module to Apache::Clean (see Listing 7.9 as a basis) called, say,
Apache::Clean::Exception. That means in my module's directory I would
have:
Clean.pm
Clean/Exception.pm
In the module Clean.pm I would load the related Exception module:
use Apache::Clean::Exception;
In modules that I have written where it does not use Apache::ExtUtils
in Makefile.PL this is not a problem - so I know I'm not toally out to
lunch! Turns out what is happening is that Apache::ExtUtils tries to
use Apache::Clean which ends up failing because the use
Apache::Clean::Exception therein fails. The INC path isn't tweaked
appropriately.
I tried to structure my packages like:
lib/Apache/Clean.pm
lib/Apache/Clean/Exception.pm
and
Apache/Clean.pm
Apache/Clean/Exception.pm
They didn't work either. Hmmm. Odd. Well, I still want that module to
load at some point - so what do I do?
Once the module is built and properly installed things go away - so my
module isn't really problem - that leaves Makefile.PL and friends. Ah
ha! Why not pre-load Apache::Clean::Exception (the problem in the
first place) from Makefile.PL?
So put my files back to how I wanted them in the first place:
Clean.pm
Clean/Exception.pm
Makefile.PL
And inside of Makefile.PL I put:
package Apache::Clean;
require Clean/Exception.pm;
# however that doesn't quite do the trick since
# it must show as Apache::Clean::Exception having been loaded
# this is just Clean::Exception - which is not the same
# - solution? Fiddle with %INC
$INC{'Apache/Clean/Exception.pm'}=$INC{'Clean/Exception'};
# Of course you could change your module's directory structure to
# feature Apache in the path to begin with.
__END__
Now things work nicely for me!
--
SECOND HINT - Modules that use directives are testy about being tested
If you reference one of these modules via PREREQ_PM or try some tests
outside of Apache (it IS possible after all) they will fail at the
bootstrap method.
in your module (ie/ Clean.pm) change:
PACKAGE__-bootstrap($VERSION);
to
PACKAGE__-bootstrap($VERSION) if $ENV{'mod_perl'};
Voila - at least now you should have no complaints via MakeMaker
checking for PREREQ_PM and you can even do some tests - which no doubt
you've been anxious to write!!
---
Did all that make sense? I hope so - if not I shall endevour to
clarify.
Cheers,
Jay
Re: [ANNOUNCE] The New mod_perl logo - results now in...
DRI really like the new logo, and in fact I voted for it. However, I just DRrealized that the logo uses modperl, whereas mod_perl's name is DRmod_perl, with the underscore. Does anyone else see this as a problem? BMIt's a graphic design so I don't see that it needs to follow the Apache BMmodule naming convention exactly... It's a design -- it doesn't have to BMbe accurate to the name. A thought - what about putting the suggestion of an underscore by putting bars underneath the d and p of modperl? Just a suggestion to Michael as presumably he is revisting the design for the buttons. J
Re: [ANNOUNCE] The New mod_perl logo - results now in...
A thought - what about putting the suggestion of an underscore by putting bars underneath the d and p of modperl? Just a suggestion to Michael as presumably he is revisting the design for the buttons. This is a funny discussion. Although not my favorite Logo has been elected, I confirm the need of a uniform design over all logo representations! so why do we cling to mod_perl as a name? i suppose for the familiar historical reasons, it's a fond term of endearment to us. but it would be more descriptive to call it The Apache perl API or Apache-Embedded perl, would it not? it behooves us to ride along on Apache's name-recognition doesn't it? To make things thing even more complicated I agree the need of a name with a sounding image, which will help mod_perl to grow into corporate computing (our future jobs). Recently I had a discussion with a Java programmer, who said that mod_perl is a try to save the obsolete language Perl. His argument was that only Java programmers are searched, especially here in Europe. So I see three requirements: - Having a name and logo which tells the truth, it's Perl and it was good. - The name should defer to Perl, should be it's own brand. - The sounding must be stronger then API putting bars underneath the d and p of modperl? Just a suggestion First I liked the idea 'DP' oder 'dPerl'. On the other hand we have the A, which stands for Apache, Application ... A is first, is best. So I came to aPerl or Parl 'Practical Application R* Language'? On and on just some funny thoughts :-) BR Christian == beginn original == Date: Freitag, 15. März 2002, 11:03:59 Subject: [ANNOUNCE] The New mod_perl logo - results now in... Fellow mod_perl hackers... It is with great pleasure that I am able to introduce you to the new mod_perl logo. So, without further ado, point your web-browsers at: http://beverley2.digital-word.com/mod_perl/winner/ The winning logo, designed by Michael Demers (mike [at] inteo.com), won by a very clear majority. Congratulations Mike, and thanks for a great effort! The new mod_perl button vote resulted in a tie between two designs: Juergen Spechts' (the existing button) and new design by Tyler Rorabaugh. Following a brief discussion with Stas (stas [at] stason.org), I think it might be a good idea to have several mod_perl buttons, the idea being that a designer can then choose a button that doesn't conflict with his/her design. However, I request your comments on this idea: should we have just one button (helping to develop a distinct identity for mod_perl) or should we have several (for choice)? It's up to you... Thank you to everyone who participated in this project. Kudos to the designers for their efforts. Thanks to Stas for his input and ideas, and Eric Cholet for the voting script. Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/ -- Temporarily off-line http://wypug.digital-word.com/ === end original
Minimum config for proxy+mod_perl / mod_define.so ?
Hi, in a 2-server-on-one-machine-environment (proxy/mod_perl) I try to slim especially the proxy httpd as much as possible by removing all unneeded modules. Please help me at 2 questions: 1. What is the minimum of modules to be loaded for the proxy and the mod_perl apache? (Ok, I'm about to find out by trial and error, but maybe someone has a working solution). 2. What is the purpose of this module: LoadModule define_module /usr/lib/apache/mod_define.so I can't find it in the docs. I'm running Apache/1.3.19 on SuSE Linux 7.2 (i386). Xanx! Ernest -- * * VIRTUALITAS Inc. * * ** * * European Consultant Office * http://www.virtualitas.net * * Internationales Handelszentrum * contact:Ernest Lergon * * Friedrichstraße 95 *mailto:[EMAIL PROTECTED] * * 10117 Berlin / Germany * ums:+49180528132130266 * *
RE: loss of shared memory in parent httpd
I believe I have the answer... The problem is that the parent httpd swaps, and any new children it creates load the portion of memory that was swaped from swap, which does not make it copy-on-write. The really annoying thing - when memory gets tight, the parent is the most likely httpd process to swap, because its memory is 99% idle. This issue aflicts Linux, Solaris, and a bunch of other OSes. The solution is mlockall(2), available under Linux, Solaris, and other POSIX.1b compliant OSes. I've not experimented with calling it from perl, and I've not looked at Apache enough to consider patching it there, but this system call, if your process is run as root, will prevent any and all swapping of your process's memory. If your process is not run as root, it returns an error. The reason turning off swap works is because it forces the memory from the parent process that was swapped out to be swapped back in. It will not fix those processes that have been sired after the shared memory loss, as of Linux 2.2.15 and Solaris 2.6. (I have not checked since then for behavior in this regard, nor have I checked on other OSes.) Ed On Thu, 14 Mar 2002, Bill Marrs wrote: It's copy-on-write. The swap is a write-to-disk. There's no such thing as sharing memory between one process on disk(/swap) and another in memory. agreed. What's interesting is that if I turn swap off and back on again, the sharing is restored! So, now I'm tempted to run a crontab every 30 minutes that turns the swap off and on again, just to keep the httpds shared. No Apache restart required! Seems like a crazy thing to do, though. You'll also want to look into tuning your paging algorithm. Yeah... I'll look into it. If I had a way to tell the kernel to never swap out any httpd process, that would be a great solution. The kernel is making a bad choice here. By swapping, it triggers more memory usage because sharing removed on the httpd process group (thus multiplied)... I've got MaxClients down to 8 now and it's still happening. I think my best course of action may be a crontab swap flusher. -bill
Re: loss of shared memory in parent httpd
Yes, this is my theory also. I figured this out a while back, and started a thread on this list, but since then haven't had enough time to investigate it further. The thread is here: http://mathforum.org/epigone/modperl/wherdtharvoi which includes some helpful hints from Doug on how to call mlockall() from the mod_perl parent process. HTH.. I'm very curious to know if this works. -Adi Ed Grimm wrote: I believe I have the answer... The problem is that the parent httpd swaps, and any new children it creates load the portion of memory that was swaped from swap, which does not make it copy-on-write. The really annoying thing - when memory gets tight, the parent is the most likely httpd process to swap, because its memory is 99% idle. This issue aflicts Linux, Solaris, and a bunch of other OSes. The solution is mlockall(2), available under Linux, Solaris, and other POSIX.1b compliant OSes. I've not experimented with calling it from perl, and I've not looked at Apache enough to consider patching it there, but this system call, if your process is run as root, will prevent any and all swapping of your process's memory. If your process is not run as root, it returns an error. The reason turning off swap works is because it forces the memory from the parent process that was swapped out to be swapped back in. It will not fix those processes that have been sired after the shared memory loss, as of Linux 2.2.15 and Solaris 2.6. (I have not checked since then for behavior in this regard, nor have I checked on other OSes.) Ed On Thu, 14 Mar 2002, Bill Marrs wrote: It's copy-on-write. The swap is a write-to-disk. There's no such thing as sharing memory between one process on disk(/swap) and another in memory. agreed. What's interesting is that if I turn swap off and back on again, the sharing is restored! So, now I'm tempted to run a crontab every 30 minutes that turns the swap off and on again, just to keep the httpds shared. No Apache restart required! Seems like a crazy thing to do, though. You'll also want to look into tuning your paging algorithm. Yeah... I'll look into it. If I had a way to tell the kernel to never swap out any httpd process, that would be a great solution. The kernel is making a bad choice here. By swapping, it triggers more memory usage because sharing removed on the httpd process group (thus multiplied)... I've got MaxClients down to 8 now and it's still happening. I think my best course of action may be a crontab swap flusher. -bill
Re: Minimum config for proxy+mod_perl / mod_define.so ?
Oh, sorry, I forgot: httpd -l gives: Compiled-in modules: http_core.c mod_so.c suexec: enabled; valid wrapper /usr/sbin/suexec The rest is DSO. Ernest
Re: [OT][ANNOUNCE] The New mod_perl logo - results now in...
On Sat, 2002-03-16 at 08:01, [EMAIL PROTECTED] wrote: Recently I had a discussion with a Java programmer, who said that mod_perl is a try to save the obsolete language Perl. His argument was that only Java programmers are searched, especially here in Europe. Interesting. I have a friend that works for Sun whos job it is to find companies and products that use Java and compile them into a database of success stories. His job has become increasingly difficult over the past year. Arguments about being obsolete aside, of Java and Perl, one language is seems to be growing and one seems to be dying...
RE: loss of shared memory in parent httpd
The reason turning off swap works is because it forces the memory from the parent process that was swapped out to be swapped back in. It will not fix those processes that have been sired after the shared memory loss, as of Linux 2.2.15 and Solaris 2.6. (I have not checked since then for behavior in this regard, nor have I checked on other OSes.) In my case, I'm using Linux 2.4.17, when I turn off swap and turn it back on again, it restores the shared memory of both the parent and the children Apache processes. This seems counter-intuitive, as it would seem the kernel memory manager would have to bend over backwards to accomplish this re-binding of the swapped-out shared memory pages. Thus, it leads ones to wonder if some of our assumptions or tools used to monitor memory are inaccurate or we're misinterpreting them. -bill
