<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1">
<TITLE>RE: [rt-users] FastCGI vs/or FastCGId? System memory "leak"?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=2>-----Original Message-----<BR>
From: rt-users-bounces@lists.bestpractical.com on behalf of Tomas Olaj<BR>
Sent: Mon 2/6/2006 3:55 AM<BR>
To: Justin Zygmont<BR>
Cc: rt-users@lists.bestpractical.com<BR>
Subject: Re: [rt-users] FastCGI vs/or FastCGId? System memory "leak"?<BR>
<BR>
On the marvelous Wed, 1 Feb 2006, Justin Zygmont wrote kindly to me ...<BR>
<BR>
>>> Jesse mentioned at the Amsterdam class that mod_FCGId is another<BR>
>>> alternative (<A HREF="http://fastcgi.coremail.cn/">http://fastcgi.coremail.cn/</A>) to mod_FastCGI, and I will have<BR>
>>> a closer look at this source. And, the source code looks newer and<BR>
>>> maintained. ;)<BR>
>><BR>
>><BR>
>><BR>
>> Hello,<BR>
>> did anybody use fcgid successfully to replace fascgi? I would love an<BR>
>> rt-specific configuration sample.<BR>
>><BR>
>> Regards,<BR>
>> Harald<BR>
><BR>
> I tried it, and it seemed to work great, until a few users noticed a place<BR>
> where they could not create a ticket. When I switched it back to cgi, or<BR>
> fastcgi, it worked again. So much for using that...<BR>
><BR>
> Meanwhile, I can the fastcgi processes slowly taking up more and more ram.<BR>
<BR>
I really haven't got time to test FCGId. Do You say that this software<BR>
is not recommendable? Could there be other alternatives than FastCGI?<BR>
FastCGI works, but it consumes memory, and I worry because no one<BR>
maintains the source code.<BR>
<BR>
--<BR>
________________________________________________________________________<BR>
Tomas A. P. Olaj, email: tomas.olaj@usit.uio.no, web: folk.uio.no/tomaso<BR>
University of Oslo / USIT (Center for Information Technology Services)<BR>
System- and Application Management / Applications Management Group<BR>
_______________________________________________<BR>
<A HREF="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users">http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users</A><BR>
<BR>
I gave up on FastCGI when I saw what was involved getting it to work<BR>
with apache2 under red Hat Enterprose linux. The endless HTML rubbish that<BR>
FastCGI will dump into the syslog when it throws an exception<BR>
completely defeats the purpose of system logs with one line informative<BR>
messages. The punishment for FastCGI's lack of consideration for my system<BR>
was a corresponding lack of consideration of it. I decided to use mod_perl.<BR>
At first, the situation with Apache 2.2.0 and mod_perl2 weren't much better.<BR>
The calls to the Apache compatibility library begin with ap_null_handler,<BR>
and descended from there to abysmal depths...Apparently, Apache 2.x jettisoned<BR>
the apache compatibility library at some point (perhaps Apache 2.1). I would<BR>
have had to revert to an earlier Apache 2. I ended up compiling mod_perl1<BR>
version 1.26 with apache 1.13.34, since this combination seems to be<BR>
the one recommended (ever so slightly more than FastCGI on the bestpractical site),<BR>
and mod_perl1 seems to be considered more stable than mod_perl2. This choice<BR>
resulted in my first working system, though it could have been influenced by<BR>
"learning experiences" I had during the process. This was on a Debian sarge system.<BR>
I avoided apt-get and chose to compile the necessary software.<BR>
<BR>
FL</FONT>
</P>
</BODY>
</HTML>