Re: [ANNOUNCE] The New "mod_perl" logo - results now in...
In article <001401c1cc08$bab4f2b0$b1a1a8c2@orpheus>,
Jonathan M. Hollin <[EMAIL PROTECTED]> wrote:
> However, I request your comments on this idea...
Was there a button in the same style as the winning logo? Could Michael
be persuaded to create one if not?
I'm inclined to think a new logo is little use if you're not consistent
with the imagery it uses. Tying a button design into that imagery is,
IMO, essential.
All the best,
Andrew.
--
perl -MLWP::Simple -e 'getprint("http://www.article7.co.uk/res/japh.txt";);'
Re: Memory query
In article <[EMAIL PROTECTED]>,
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> If you actually want to free the memory, you need to undef it. The
> untie prevents it from persisting, but the memory stays allocated
> unless you undef.
OK, I think I'm probably handling this properly then, after all.
In a Registry script, I typically tie the hash to a package global, and
pass a reference to that hash to any routines in my library modules. At
the end of the script, the hash is untied and the package global undefed.
Many thanks,
Andrew.
--
perl -MLWP::Simple -e 'getprint("http://www.article7.co.uk/res/japh.txt";);'
Memory query
Morning all,
Forgive the naivete, but I'm having trouble wrapping my mind around the
memory implications of using tied hashes, and I haven't found anything in
the Camel book or the Guide to clarify the situation for me.
A fair amount of my Registry scripts need to use code not unlike the
following:
use strict;
use Fcntl;
use MLDBM qw(DB_File Storable);
[...]
tie(my %hash, 'MLDBM', $filename, O_RDONLY, 0644)
or die "Denied $filename: $!\n";
foreach my $item (keys %hash) {
action(\%hash,$item);
}
untie %hash;
I'm intrigued about the memory implications of this kind of construction
where the MLDBM hash is potentially very large. In particular, I'm
looking for reassurance that passing a reference to a hash doesn't copy
the hash itself into memory in any way, and that the memory overhead is
only as large as the largest $item.
Similarly, if I was to
use vars(%hash);
and initialise the tied hash as a global, does this have a significant
memory overhead? Does untie-ing the hash clear the hash contents from
memory, or do I also need to undef the hash to avoid the hash contents
persisting from one request to the next? Is one approach better than the
other?
As I said, my apologies for the newbieness of all this, and even bigger
apologies if it represents an FAQ that I've missed spotting.
Many thanks,
Andrew.
--
perl -MLWP::Simple -e 'getprint("http://www.article7.co.uk/res/japh.txt";);'
Re: PerlPassEnv and Proxies
In article <[EMAIL PROTECTED]>,
Hans Juergen von Lengerke <[EMAIL PROTECTED]> wrote:
> I agree, its a big hack, but it works :-)
Thanks to both of you for pointing me in the right direction. I guess
it's obvious, really, that environment variables don't get passed along
proxies. Blast. =o)
I've implemented a variation on your hack, and I'm very happy with it.
It also inspired me to get a further variation going as a method of
getting the original remote host without the trouble of installing
mod_proxy_add_forward. In the vanilla Apache:
RewriteRule ^/(.*)$
http://domain:port/%{REMOTE_HOST}/$1 [P,L]
...and in the mod_perl one:
RewriteRule ^/([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)/(.*)$
/$2 [E=ORIGINAL_REMOTE_HOST:$1,L]
Probably best to combine this with
Order Deny,Allow
Deny from all
Allow from localhost
To avoid *really* trivial IP spoofing!
Many thanks again,
Andrew.
--
::
article seven Andrew Green
automatic internet [EMAIL PROTECTED] | www.article7.co.uk
PerlPassEnv and Proxies
Hi all, I'm using a typical dual-server combination for mod_perl content on a selection of sites. Requests go to the vanilla Apache and a mod_rewrite/mod_proxy combo forward them on to the mod_perl Apache. As part of this, I'm trying to allow a prefix to the URL path to set an environment variable I can then use in my mod_perl programs to determine databases, templates etc. The vanilla httpd.conf features a line thus: RewriteRule ^/(test|access|ewok)/(.*)$ http://spare.article7.co.uk:8080/page/$2 [P,E=A7_FRAMEWORK:$1,L] (ignoring the wrapping). I also set PerlPassEnv A7_FRAMEWORK in my mod_perl httpd.conf -- but that environment variable always remains undef. The order of the P,E,L flags doesn't seem to make a difference. I appreciate that this is perhaps more of a mod_proxy issue than a mod_perl one, but I suspect I'm not alone in having tried something similar. I haven't found anything in the guide that deals with this specifically (I really don't want to append the information as a query string), but if I've overlooked anything, I'd be very happy to be corrected. Many thanks in advance, Andrew. -- "It seems today that all you see are violins in movies and sax on TV."
Re: PerlRun Gotchas?
[My apologies for two copies of my original message turning up. My bad.] In article <00a901c1a44d$7d087d70$18020c0a@PerriHar>, Perrin Harkins <[EMAIL PROTECTED]> wrote: > I would not expect PerlRun to use less memory than Registry. What I meant was that I have about a dozen of these little scripts. My understanding is that PerlRun uses the embedded Perl interpreter, but compiles and executes the scripts individually on each request, whereas Registry caches the compiled version, potentially meaning a dozen compiled versions cached for each of a bunch of processes. I figured using PerlRun would avoid that, but provide a useful intermediate performance boost by not forking perl each time. Have I misunderstood? > Does the module have a package name? Are you exporting the variables > from it? Seeing some code would help. It does, and what confuses me is the intermittent nature of the problem. Anyway, here's some code (snipped wildly into a minimal test case, and with the paths replaced): The module: #!/usr/bin/perl package Article7::Woking::Overseer; use strict; require Exporter; use vars qw(@ISA @EXPORT $root $dbmx); @ISA = qw(Exporter); @EXPORT = qw($dbmx); $dbmx = 'path-to-data-files'; 1; ...and the PerlRun program: #!/usr/bin/perl use strict; use CGI qw(:standard); use Fcntl; use MLDBM qw(DB_File Storable); use lib 'path-to-directory'; use Article7::Woking::Overseer; print header(-type => 'text/html; charset=utf-8'); tie(my %accom, 'MLDBM', "$dbmx/accom.dbmx", O_RDONLY, 0644) or die "Can't open $dbmx/accom.dbmx: $!\n"; [...] The error log reveals that it's this tie that kills the program -- $dbmx remains undef, so the file isn't found. > > 200 OK > That just means the error happened after the initial header was sent. Ah, I see. Yes, of course -- the first thing I do is send the header! Thanks for the ref to the Guide -- I've looked through that section again now, but I think I must be still missing something. I'm afraid running in single-server mode would be troublesome, as the server is in production use for other sites. Many thanks for your help, Andrew. -- "Mind you, you'd expect that of cows, wouldn't you? Two stomachs, know what I mean?"-- Liza Tarbuck
PerlRun Gotchas?
Hi, A site I run uses a fair variety of different programs, the most common of which are run through Apache::Registry. To cut the memory overhead, however, less commonly used programs are run through Apache::PerlRun. Both the Registry and PerlRun programs use a common module which defines a few subroutines and a selection of exported variables. These variables are in the module as globals (ie: no "my" declaration), but with a "use vars" to get them through strict. With seeming 50/50 frequency, the PerlRun programs work as intended, or alternatively return: 200 OK The server encountered an internal error or misconfiguration... ...More information about this error may be available in the server error log. Yes, it's not HTTP 500, it is 200. The error log indicates every time that this is due to a global set in my module that remains undef for the program that tries to call it (and an open that dies on failure requires the global). Hitting refresh normally does the trick. The moment I move from PerlRun to ordinary CGI, the problem vanishes. Equally, it doesn't happen for Registry. I've searched the guide, but couldn't find anything of help. I have a use Apache::PerlRun (); in my startup file, the common module is also preloaded therein, and are also "use"d in the PerlRun programs themselves. I'm running mod_perl 1.23 on Apache 1.3.19 (Red Hat). Any suggestions gratefully appreciated. Cheers, Andrew. -- "Wow, that's almost as fun as meowing." -- http://www.exit109.com/%7Ejeremy/news/providers/4groups.html
PerlRun Gotchas?
Hi, A site I run uses a fair variety of different programs, the most common of which are run through Apache::Registry. To cut the memory overhead, however, less commonly used programs are run through Apache::PerlRun. Both the Registry and PerlRun programs use a common module which defines a few subroutines and a selection of exported variables. These variables are in the module as globals (ie: no "my" declaration), but with a "use vars" to get them through strict. With seeming 50/50 frequency, the PerlRun programs work as intended, or alternatively return: 200 OK The server encountered an internal error or misconfiguration... ...More information about this error may be available in the server error log. Yes, it's not HTTP 500, it is 200. The error log indicates every time that this is due to a global set in my module that remains undef for the program that tries to call it (and an open that dies on failure requires the global). Hitting refresh normally does the trick. The moment I move from PerlRun to ordinary CGI, the problem vanishes. Equally, AFACT, it doesn't happen for Registry. I've searched the guide, but couldn't find anything of help. I have a use Apache::PerlRun (); in my startup file, the common module is also preloaded therein, and are also "use"d in the PerlRun programs themselves. I'm running mod_perl 1.23 on Apache 1.3.19 (Red Hat). Any suggestions gratefully appreciated. Cheers, Andrew. -- "Wow, that's almost as fun as meowing." -- http://www.exit109.com/%7Ejeremy/news/providers/4groups.html
Re: Preloading Fcntl.pm
In article <[EMAIL PROTECTED]>, Stas Bekman <[EMAIL PROTECTED]> wrote: > Andrew Green wrote: > > The *really* peculiar thing is that actual scripts that "use Fcntl" > > work with no problems -- but I can't preload the module, or preload > > other modules that use it. > Hmm, how about upgrading modperl? I've now finally managed to upgrade mod_perl to 1.23, and the problem has completely disappeared. I didn't even need $Apache::Server::ReStarting (which isn't available on 1.21) to be checked in the end. Many thanks to everyone for your help. Cheers, Andrew. -- :: article seven Andrew Green automatic internet [EMAIL PROTECTED] | www.article7.co.uk
Re: Preloading Fcntl.pm
In article <[EMAIL PROTECTED]>, Stas Bekman <[EMAIL PROTECTED]> wrote: > Weird, what Perl version are you using? Can you do: > perl -MFcntl -le1 > or > perl -le 'require Fcntl' Both seem to work (producing no output, but no errors either). The *really* peculiar thing is that actual scripts that "use Fcntl" work with no problems -- but I can't preload the module, or preload other modules that use it. According to /perl-status, I'm using perl 5.00503 for Apache 1.3.19 on Red Hat 6.2, mod_perl 1.21. On processes that have accessed these scripts, Fcntl shows up on /perl-status?inc and claims to be version 1.03. If it's any help, HTML::Entities displays exactly the same behaviour (and claims to be version 1.22). Cheers, Andrew. -- :: article seven Andrew Green automatic internet [EMAIL PROTECTED] | www.article7.co.uk
Re: Preloading Fcntl.pm
In article <[EMAIL PROTECTED]>, Stas Bekman <[EMAIL PROTECTED]> wrote: > Try to call: > require Fcntl; > instead. Thanks for the tip. I'm afraid the above verbatim produces the following error on restart: | Shutting down http:[ OK ] | Starting httpd: [Mon Dec 10 20:41:18 2001] [error] syntax error at | /etc/httpd/lib/perl/modperl.pl line 14, near "require Fcntl" | BEGIN not safe after errors--compilation aborted at | /etc/httpd/lib/perl/modperl.pl line 15. | Syntax error on line 395 of /etc/httpd/conf/httpd.conf: | syntax error at /etc/httpd/lib/perl/modperl.pl line 14, near "require | Fcntl" | BEGIN not safe after errors--compilation aborted at | /etc/httpd/lib/perl/modperl.pl line 15. | [FAILED] I should note that /etc/httpd/lib/perl/modperl.pl is my startup script, and that line 395 of httpd.conf is the PerlRequire directive. Beyond that, I'm not at all sure whether the above is especially instructive. Changing the startup script to: require "Fcntl.pm"; instead avoids the error, but displays the same "pretends-to-restart-OK-but-actually-doesn't" behaviour I described before. I should also mention that trying a PerlModule directive instead doesn't help either. It's very bewildering! Cheers, Andrew. -- :: article seven Andrew Green automatic internet [EMAIL PROTECTED] | www.article7.co.uk
Re: Preloading Fcntl.pm
In article <[EMAIL PROTECTED]>, Robin Berjon <[EMAIL PROTECTED]> wrote: > Have you tried to see if it works without the trailing () ? I have, yes, and I'm afraid it makes no difference. Thanks anyway, Andrew. -- :: article seven Andrew Green automatic internet [EMAIL PROTECTED] | www.article7.co.uk
Preloading Fcntl.pm
I'm trying to use a startup script to preload a selection of common modules, but am having massive problems with Fcntl. If I use Fcntl (); either in the startup script directly or (worse) in any other modules I try to preload, Apache dies silently and immediately upon restart. Checking the syntax of httpd.conf reveals no problems, and nothing unusual is written to the error log; the only indicator is that subsequent restarts report that shutting down httpd failed, and of course actual web accesses fail. The initial restart claims to have been OK. CPAN suggests my version of Fcntl is up to date. I'm using perl 5.00503 for Apache 1.3.19 on Red Hat 6.2, mod_perl 1.21. Using the module as normal in the scripts themselves works as expected; it's only when I try to preload it that the problem takes place. TIA for any hints, Andrew. -- :: article seven Andrew Green automatic internet [EMAIL PROTECTED] | www.article7.co.uk
