[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