Mod_perl configuration problem

RT Developers
1

This is really a mod_perl problem, I think, but I figured I would
try here first.

I’ve had RT 3.6.1 running on a development machine for some time,
but now I’m trying to go into production, and having headaches,
largely because I’m not allowed to just upgrade everything the
way I want :wink:

This machine had mod_perl 1.99_xx, so I had to beg an admin
to upgrade to mod_perl 2.

In the meantime, I configured things to work with FastCGI,
and that’s working fine.

The admin finally found an RPM for mod_perl 2, and installed
it. But when I tried to switch from FastCGI to mod_perl, I
got this message in the logs:

Can’t locate object method “content_type” via package
“Apache2::RequestRec” at /var/www/rt3/bin/webmux.pl line 108.

I figured that Apache2::RequestRec wasn’t getting loaded, so
I added a “use” statement to webmux.pl. That resulted in this
error:

The ‘comp’ parameter (undef) to HTML::Mason::Request::CGI->new() was
an ‘undef’, which is not one of the allowed types: scalar object
Stack:
[/usr/lib/perl5/site_perl/5.8.5/HTML/Mason/CGIHandler.pm:127]
[/usr/lib/perl5/site_perl/5.8.5/HTML/Mason/CGIHandler.pm:63]
[/var/www/rt3/bin/webmux.pl:128]

So I gave up on trying to patch things in webmux.pl :frowning:

I think I’ve got the apache configuration right; it works
on the other machine. OTOH, that was using a new version
of apache. The machine that’s giving me trouble is on Apache/2.0.52.

I could just stick with FastCGI, but I’d like to know what’s
going wrong here.

Thanks for any pointers …

Harry

2

In the meantime, I configured things to work with FastCGI,
and that’s working fine.

The admin finally found an RPM for mod_perl 2, and installed
it. But when I tried to switch from FastCGI to mod_perl, I
got this message in the logs:

Just curious what the big attraction to switching from fcgi to
mod_perl is? RT makes no use of the deep apache integration mod_perl
offers, and fastcgi is just as clean and fast of a solution, if not
better when you have other things your web server is doing too.

smime.p7s (2.47 KB)

3

First of all, here’s a partial answer to my own question:

The problem appears to be that the RPM version of mod_perl is defective.
I ran an experiment, running another instance of apache with the same
configuration, except that it uses a mod_perl.so that I built from source,
instead of the one from the RPM. RT works fine in this instance of apache.
I still don’t know what’s wrong with the one from the RPM, but I’m
convinced
that’s where the problem is.

So I’m going to use this as an example to argue against the “RPM only”
style
of system administration.

Now, Vivek Khera asks:

Just curious what the big attraction to switching from fcgi to mod_perl
is? RT makes no use of the deep apache integration mod_perl offers, and
fastcgi is just as clean and fast of a solution, if not better when you
have other things your web server is doing too.

Actually, I like FastCGI. The architecture seems more robust. It might be
slightly slower
than mod_perl, but it’s certainly fast enough in my experience.

But there’s a separate issue of popularity. My boss feels that simply
because mod_perl is more
widely used, it’s likely to get better support, and so FastCGI is more
likely to have problems sometime
in the future.
That seems reasonable to me, although my experience with getting mod_perl
installed on the
production machine points the other way ;-(

Harry

4

Actually, I like FastCGI. The architecture seems more robust. It
might be slightly slower
than mod_perl, but it’s certainly fast enough in my experience.

But there’s a separate issue of popularity. My boss feels that
simply because mod_perl is more
widely used, it’s likely to get better support, and so FastCGI is
more likely to have problems sometime
in the future.
That seems reasonable to me, although my experience with getting
mod_perl installed on the
production machine points the other way ;-(

Take this from one of the long-time users of mod_perl and author of
the mod_perl_tuning document that comes with it… you’re not gonna
get better speed with mod_perl than with fastcgi. Why? because
unless you use some of the proxying tricks with mod_perl to shove the
non “live” page generation (ie, loading images, etc.) off of
mod_perl, you will kill your performance. mod_perl makes for very
heavy processes, and using a 100+Mb process to serve up a GIF file is
bad for your capacity.

Ultimately what you end up with is an architecture identical to that
of fastcgi, but using HTTP rather than FCGI protocol between the
heavy back-end document generating processes and the light weight
front-end http server that handles static content and proxies to the
heavy code.

For sure, mod_perl has its place, but using it with RT is not
providing any benefit beyond what fcgi gives you.

FastCGI is a primary supported mechanism in RT so don’t expect
support for it to go away anytime soon.

It also liberates you from having to use Apache as your web server
(not that I’ve done that with RT, but have with other projects).

smime.p7s (2.47 KB)