Hi,
While the mod_fcgid module hasn't received the complete input data,
nothing is sent to the FastCGI application (which isn't even aware of
such a request). And even with the mod_fcgid 2.2, there is still a bug
somewhere and apache leaks memory till death (I'm sure of it, I'm the
one who reported the bug and proposed a solution).
It is at the moment conceptually not possible to stream the data
directly to a fastcgi application (mod_fcgid buffers the entire input
data first, then tries to send it to a connected socket or spawn a new
instance). The only way to make this work would be to contact the socket
first, then buffering input data and sending it to the application by
chunks. This is not really easy with the current design, and it is why
the "buffer-to-tmp-file" workaround is used (although this workaround
doesn't work properly).
The only way to not make Apache dying, is to ... use CGI with the
application used for uploading (this is easy to do for only a specific
script with a .htaccess handler rule). This way you don't kill the
performance gained from FastCGI for your other scripts, but you disable
it for the upload script (which doesn't gain any performance from
FastCGI anyway).
And if you are wondering why this design has been chosen at the first
time by the author, this is because for *very small* input data (<64k),
buffering in the server module allows the FastCGI application to process
requests very efficiently, without waiting for input data and have too
many busy sockets. Although this is a good idea, the protocol spec and
white paper doesn't state any need for buffering before the FastCGI
application (the application has to do it itself). This way applications
can make full implementations of some data input handling such as
on-the-fly mime decoding, stream filtering, RFC1867, etc. which cannot
be handled by mod_fcgid (by design!).
Anyway, I'm thinking of building a new module design from scratch, and
maybe even coding it (I'm far better at designing than coding such
projects, though). The idea would not be to take over the mod_fcgid
module, but rather improving it and make it more conform to standards.
This would be a great step to widespread its use (what we all want).
I can provide some tools, hardware, to help test and develop that (Linux
only, not the Windows versions, sorry).
Cheers,
Gabriel
PS: Could you please use only english in your messages? ;-). It's not my
native language either, but so practical!
On 02/13/2008 7:41:28 AM +0100, "Ang FAN" <[EMAIL PROTECTED]> wrote:
> sorry, there are a wrong,
>
> while(FCGX_Accept(&request.in,&request.out,&request.err,&request.envp)
>
> shoulde be：
>
> while(FCGX_Accept_r(&request) == 0)
>
> 在 08-2-13，Ang FAN<[EMAIL PROTECTED]> 写道：
>> Hi,
>> Thank you,but I do that as you say,the memory still keep growing.
>>
>> 你好，用中文吧，我按你说的改了，但是内存(apache)还是不停的长，我的程序是这样写的，你看看有什么问题吗？
>>
>> int main (void)
>> {
>> streambuf * cin_streambuf = cin.rdbuf();
>> streambuf * cout_streambuf = cout.rdbuf();
>> streambuf * cerr_streambuf = cerr.rdbuf();
>>
>> FCGX_Request request;
>> FCGX_Init();
>> FCGX_InitRequest(&request, 0, 0);
>>
>> DWORD dwPrePrcoess = 0;
>>
>>
>> while(FCGX_Accept(&request.in,&request.out,&request.err,&request.envp)
>> == 0)
>> {
>>
>> fcgi_streambuf cin_fcgi_streambuf(request.in);
>> fcgi_streambuf cout_fcgi_streambuf(request.out);
>> fcgi_streambuf cerr_fcgi_streambuf(request.err);
>> #if HAVE_IOSTREAM_WITHASSIGN_STREAMBUF
>> cin = &cin_fcgi_streambuf;
>> cout = &cout_fcgi_streambuf;
>> cerr = &cerr_fcgi_streambuf;
>> #else
>> cin.rdbuf(&cin_fcgi_streambuf);
>> cout.rdbuf(&cout_fcgi_streambuf);
>> cerr.rdbuf(&cerr_fcgi_streambuf);
>> #endif
>> ResultState nResult = HandleRequest(
>> &request,paramData,strErrcode);
>>
>> cout << "Content-type: text/html\r\n\r\n";
>> if(strErrcode.IsEmpty())
>> cout << ResultStateText[nResult];
>> else
>> cout << CStringA(strErrcode);
>>
>> FCGX_Free(&request,TRUE);
>> }
>>
>> #if HAVE_IOSTREAM_WITHASSIGN_STREAMBUF
>> cin = cin_streambuf;
>> cout = cout_streambuf;
>> cerr = cerr_streambuf;
>> #else
>> cin.rdbuf(cin_streambuf);
>> cout.rdbuf(cout_streambuf);
>> cerr.rdbuf(cerr_streambuf);
>> #endif
>> return 0;
>> }
>>
>> 在 08-2-13，潘庆峰<[EMAIL PROTECTED]> 写道：
>>> 1. upgrade your mod_fcgid to 2.2
>>> 2. mod_fcgid 2.2 support a new configuration "MaxRequestInMem" (default
>>> 64k), every http request longer than 64k will swap to tmp file
>>>
>>>
>>>
>>>
>>> 在2008-02-13，"Ang FAN" <[EMAIL PROTECTED]> 写道：
>>>
>>> ---------- Forwarded message ----------
>>> From: Ang FAN <[EMAIL PROTECTED]>
>>> Date: 2008-2-13 11:49
>>> Subject: Re: confirm
>>> 1fdecc4c927c4c9e3e26a2a2bc779e5cc2c36c12
>>> To: [EMAIL PROTECTED]
>>>
>>>
>>> Hi,
>>> I used fcgid as a file uploader server modul(window 2003 server),but
>>> if the files are big, it will take the apache memory grow up until the
>>> apache server crash, why?
>>>
>>> thanks!
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Mod-fcgid-users mailing list
>>> Mod-fcgid-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
>>>
>>>
>>>
>>> ________________________________
>>> 网 易 有 道 英 汉 电 子 词 典 获 2 0 0 7 年 " 电 脑 报 " 免 费 软 件 最 佳 功 能 奖
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Mod-fcgid-users mailing list
>>> Mod-fcgid-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
>>>
>>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Mod-fcgid-users mailing list
>> Mod-fcgid-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Mod-fcgid-users mailing list
Mod-fcgid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
