I've been following along with this thread with interest, expecially since I'm
new to the mod_perl list and community (thanks for all the help so far!). I
thought you might be interesed in a 'mod_perl newbie' opinion.
Recently I was handed an online event calendar running under CGI and asked to
get it to run under mod_perl to speed it up. I'm comfortable with perl, but by
no means a guru. And this was the first time using mod_perl. In the past I've
used several products which might be considered competitors to mod_perl: Web
Objects and Cold Fusion. CF was horrible, I'm glad I didn't have to work with it
for long. WO was very nice to work with, and it had all the ecommerce and
transation logic needed to build a enterprise web application quickly. (None of
my work has been in ecommerce, instead in the medical industry (patient data,
lab results, etc) which has many of the same requirements).
Installing:
I've installed mod_perl twice in the last month. The first time was on Solaris
and was quite painless. The second time was on RH 7.0, and was fairly painful.
Took most of a day of futzing around to finally get it installed and working. I
ran into two problems, first the unrecognized version of apache 1.3.14, and
second when I had downgraded to 1.3.12 the new auto-configure part of apache was
bypassing the standard Configuration file which mod_perl had inserted itself
into, so Apache was building itself without mod_perl.
As several others have said here, there is work which could be done in this
area. My suggestions would be:
- easier install in general (big red button approach is always nice)
- make it easier (clear instructions too) on how to configure apache with
mod_perl and other modules. The current 'big red button' only works if you have
no other modules or already have them configured.
- Instructions written for someone who knows nothing about mod_perl, and
possible very little about unix. This is a general problem for all open source
projects. With today's IT shortage, more and more sys admins are just power
users who were promoted or sucked into duties because someone else left. If you
want to catch their eye, make sure you talk at their level. I realize this can
be a pain in you know where, and it's something that as you look to advocate you
need to think about. "Do we want to target everyone, or should there be a
minimum level or aptitude before we recommend someone installs this?" Anyone can
walk into Staples these days and install Linux. If they have a decent
distribution installing everything is easy. But even without a package manager
like RH, apache is usually very painless to install. I know a number of
non-profits who just have competent users maintaining a Linux server with
apache, because for the most part it's trouble free. At worst they might have to
restart the server.
Technical Issues:
The second problem I see with mod_perl is a technical one. Because of the design
of mod_perl, debugging problems can be fairly involved. Is the problem my code?
Or is it apache, or maybe mod_perl? Could even be perl for that matter. Take for
example the problem I ran into recently. (Please don't take this as a rant just
because I had problems, I'm happy with mod_perl. But I'm fairly capable around
unix and compiling, instead imagine this happening to someone who wasn't that
comfortable.)
The event calendar works great under CGI, so I try it under mod_perl. It was
written to work under mod_perl by a better perl programmer that I'll ever be
(Jon Howell of Faq-o-matic fame) and is very well designed. It even worked under
mod_perl with some minor changes like supplying the user/pass to the database
since it wasn't running under cgiwrap any longer. And it worked! But only 90% of
the time.
The other 10% of the time, the client received no data, and the page generated
by the script ended up in the apache log. After cleaning up one implicit
database handle destruction warning the problem persisted, and I began to
attempt to discover where the connection was being closed. So I did what any
lazy programmer does, I added some print statements to send a note to STDERR.
While these all showed up when the program worked correctly, when problem
occured, the prints to STDERR dissapeared. But the html page was printed to the
apache log, basicly standard error. So it looks like if the socket is closed,
stderr dissapears, and stdout goes to the error log. So no pointers appeared in
the log, which wasn't very helpful.
Next attempt was to do some packet sniffing to see why the socket was closeing.
Turns out that the web server sends an orderly release indication (T_ORDEL_IND =
132), so the client being a good citizen reponds with a orderly release request
and there goes the socket.
While my description of the problem was more in-depth that I meant it to be, my
point is that now I'm left with the need to trace through system calls made by
apache, mod_perl and my program to try and find who's asking the client to kill
the connection. It's a pain for me (expecially since this is all running on Dec
Unix which doesn't have a system call trace funtion), I can't imagine what it
would be like for some newbie sys admin.
Unfortunatly I don't see any way around this problem. Due to the design of
mod_perl, understanding the debuging the whole system is nessisary. And before
anyone says this is the strength of open source software (of which I am an
advocate) most people are just trying to get something up and running. They
probably don't have the time or the expertice to go looking through code to
figure out what's going wrong.
Steve Cochran
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
