All the Perl that's Practical to Extract and Report

Snatched From The Hands of Victory

shockme on 2003-11-14T20:58:03

Grrr....

My script works fine as a standard CGI script. Running under mod_perl, it's sporadic and unpredictable. Sometimes it works, sometimes it craps with an error (but hitting Reload will lead to the proper results), sometimes it will only display the left column. Searching is out of the question. I've yet to get that to work. Hell, the log files don't even show the search request hitting the system.

I've stopped and started Apache so many times that my history file has been rendered useless.

Different browsers give the exact same result, so I know it's not a browser issue.

Other than installing mod_perl and changing httpd.conf, I've changed nothing.

You can compare and contrast as follows:

mod_perl: http://exitwound.org/perl
CGI: http://exitwound.org/music/index.pl

Note the continued necessity of index.pl on the CGI version. God this is fun ...



Posted from exitwound.org, comment here.

No Difference Here

phillup on 2003-11-15T16:52:24

Either you fixed it, or you really do have some browser caching issues.

I dl'd both links, five times each... using wget and the -S option so I could see the server responses.

I also diff'd the files to make sure my eyes were not playing tricks on me.

All files are identical.

I have found that I can greatly reduce browser caching by adding two meta statements to the head section. (I'm leaving out the angle brackets on the ends)

meta http-equiv="Pragma" content="no-cache"
meta http-equiv="Expires" content="-1"

YMMV, but I'd add these to the script... and I'd double check the browser cache settings... and, lastly... I'd use wget as a backup check to make sure the browser isn't fibbing. They do that a lot.

P.S.

phillup on 2003-11-15T16:54:53

Both links only show the left column.

Re:No Difference Here

shockme on 2003-11-15T19:11:04

Very cool. I'll check into this. Thanks.

Re:No Difference Here

shockme on 2003-11-15T19:14:32

Try these links:

http://exitwound.org/perl/index.pl?method=ByArtist
http://exitwound.org/music/index.pl?method=ByArtist

I'll check the diffs with a wget later today. That's a great idea.

Re:No Difference Here

phillup on 2003-11-15T20:51:45

>http://exitwound.org/perl/index.pl?method=ByArtist

This one gave me various responses when it worked. And it gave an error message at times... but returned a status of 200, which is technically OK. But, it did state that there was an internal error.

>http://exitwound.org/music/index.pl?method=ByArtist

This one seemed to work consistently.

This might be a stupid question... but... did you "use strict;" as near the top of the script as you can? Helps me find silly typos all the time...

Some feel that use strict is too constraining... all I know is, a web server should be constrained.

Just my opinion.

In a cgi environment your script starts fresh every time, so things like variable initiation aren't a big deal.

But, in a mod_perl environment... the script hangs around. So, if you have a variable that Perl was nice enough to create for you on the fly the first time the script ran... it won't do it the second time thru. Instead, the variable will have the value left over from the previous execution.

A variable created via "my" gets reinitialized each invocation. This gives you a nice, known starting point.

To make matters worse... you probably have lot's of apache children hanging out waiting to service responses... and each of them get their own perl environment. So, one time you might get serviced by kid#1 and the next time by kid#2, and they can have drastically different values for variables that aren't created by you.

"my" is your friend when you use mod_perl... IMHO

Re:No Difference Here

shockme on 2003-11-17T14:29:39

I'm using strict and warnings.

The behavior you've described is exactly what I'm talking about. Sometimes it works, sometimes it doesn't.

I looked through the script for any values that might be hanging around following exectution. The only thing I found that was created but not populated is:

my $template; # use for HTML::Template

I changed that to

my $template = ' ' ;

Still, jickiness prevails.

I really want to stick with HTML::Templates, but everything I've written that doesn't use it works great. The docs the HTML::Template indicate that most (if not all) of the caching is turned off by default, so I'm thinking I just need to rewrite the thing without the module.

Re:No Difference Here

grantm on 2003-11-18T10:00:54

Apologies if you already know this ...

If you're using Apache::Registry or similar, then you need to make sure you have no 'file scoped lexicals'. Or in English, use my for variables in subroutines but not for 'globals'. Use 'our' and they really will be globals. eg:

my $id = $query->param('id');

print get_item();

exit;

sub get_item {
# select data using $id
# stick it into the template
}

In this (silly) example, the first time the script is run it will work. The second time though it will create a new $id and assign the right value to it but the get_item subroutine will still be looking at the old variable which will still contain the old value. Each Apache/mod_perl httpd process will remember the arguments it was first invoked with - hence the apparently random results.

Simple rule: 'my' for local variable in subs and 'our' for globals.