[FASTCGI] Connection status
David Birnbaum
davidb at pins.net
Thu Oct 23 10:02:56 EDT 2008
The FastCGI protocol doesn't include anything about queue; you could check (via
system call, I would think) to see if anything is actually queued up before
dropping into the accept() if you were writing your own code. Or, you could do
what we do and automatically try to run maintenance code after you finish the
request and going back into the accept().
On the httpd side, there's no way for a given child/thread to see what other
children/threads are doing (in terms of requests). Apache does have a
scoreboard, so you could write your own code to see what's in the scoreboard
before processing a request, but that would require access to that API (either
directly if you're on the same machine, or via a /server-status type request
handled by the relevant Apache module).
Not trivial, no matter how you slice it. If your FastCGI requests aren't fast,
they probably shouldn't be running via FastCGI and should instead be broken out
to run via CGI instead. FastCGI is optimized for speed of the return request.
David.
-----
On Thu, 23 Oct 2008, Shruthi Dipali wrote:
>> Generally with fastcgi you process requests
>> so
>> quickly it seldom happens. If it does it's more trouble to detect it
>> and abort the request than it is to ignore it and let the results go
>> to the bit bucket.
>
> Hey Jay,
>
> Thanks for your response.
>
> What you say makes perfect sense. But this issue needs a fix. I can't
> quite figure out
> how else to do it.
>
> Regards,
> Shruthi
>
> On Thu, Oct 23, 2008 at 6:35 PM, Jay Sprenkle <jsprenkle at gmail.com> wrote:
>>
>>
>> On Thu, Oct 23, 2008 at 7:38 AM, Shruthi Dipali <shruthidipali at gmail.com>
>> wrote:
>>>
>>> I need a
>>> way of checking if the request that is queued is already timed out
>>> before forwarding the request
>>> to tomcat.
>>
>> I've been looking at that same code to try to detect when there are
>> pending requests so I can intelligently schedule maintenance tasks.
>>
>> I don't think mod_fastcgi, or any existing fastcgi library, have any
>> monitoring for that condition. Generally with fastcgi you process requests
>> so
>> quickly it seldom happens. If it does it's more trouble to detect it
>> and abort the request than it is to ignore it and let the results go
>> to the bit bucket.
>>
> _______________________________________________
> FastCGI-developers mailing list
> FastCGI-developers at mailman.fastcgi.com
> http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers
>
More information about the FastCGI-developers
mailing list