Re: Re: Re: How do you feel about mod_perl?

[edebill]

Yes, if you write your CGI with discipline, you can certainly get it to run unchanged under mod_perl. On the other hand, I've made the same observation about the CGI apps I've downloaded. Lots of people leave out the my's, skip the use strict;, and generally do things in a sloppy manner.

I'm sure I'll eventually download one and have it run under mod_perl without problems. But it's usually easier to just enable mod_cgi rather than debugging someone else's script.

As for developing from scratch, well, "limiting" myself to apache/mod_perl doesn't seem to be that big a loss.

YMMV, of course.

I'd be curious what you mean by "Aside from a few traps due to the way Apache::Registry namespaces compiled scripts". Are you referring to the way it treats modules with the same name found in different places in the directory structure as the same module? Quite a headache when you have 3 developers using the same webserver to work on the same app - 2 want the stable version of a module, 1 wants the version he's hacking on at the moment.

I've had trouble while debugging with mod_perl not picking up changes to modules without a webserver bounce (or setting MaxRequestsPerChild to 1). A couple of my coworkers actually have a

* * * * *    /usr/local/apache/bin/apachectl restart

cron job to work around this on their dev boxes.

ED

[blakem]

This was one of the first questions I asked on perlmonks..... The rest of the thread is rather helpful as well. Perhaps one of these methods will help you out.

-Blake

[edebill]

Our site architecture tries to isolate all non-trivial logic from the .epl files which are actually displayed. This has paid off in a large way when parts of the site have to be changed around.

Unfortunately, it means most of the core logic behind the site lives in perl modules - and changes to them aren't noticed automatically. Any method that requires explicitly reloading a given method or module is unacceptable - it would be too much work to modify all 1200 .epl files to explicitly reload every module they use.

Actually, like I said, I've already solved it. It's only a dev issue - for production we want to have as much caching as possible (to the point that we'll even cache database query results within modules). On a dev box I've found that setting MaxRequestsPerChild to 1 in the apache config file does the job (this forces apache to fork a new process for each incoming connection - which incidentally starts a new perl interpreter in mod_perl).

Makes things rather slow to run, but that's much better than adding special case code to every .epl file (~1200) for every method in one of our home-grown modules (~700).


ED

[blakem]

You should at least take a look at Apache::Reload. It only requires a small change to the modules in question... Changing the .pl files was a solution to a special case, and wouln't necessarily need to be done.

That said, I think you're fooling yourselef if you think developing in a 'MaxRequestsPerChild=1' environment is a good idea. Almost all the mod_perl related bugs have to do with the persistant nature of your code -- the fact that a single binary is running multiple scripts multiple times is being glossed over in your development environment.

I would recommend keeping your development environment as similiar to your production environment as possible. MaxRequests=1 vs MaxRequest=alot is a *huge* difference that can cause you troubles down the road.

-Blake