[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fastcgipp-users] how does fastcgi++ support multiple concurrent req

From: Eddie Carle
Subject: Re: [Fastcgipp-users] how does fastcgi++ support multiple concurrent requests ?
Date: Fri, 07 Dec 2012 20:47:30 -0700

On Wed, 2012-12-05 at 13:53 +0100, Javier de la Dehesa wrote:
> > 4. If the client is disconnected (say user closes browser), How does
> > the FCGI process get notified the request is longer valid ? Is there
> > any callback for that ?
> Well I don't know a lot about the library internals, but I don't
> really see any callback for that. The transceiver attribute is the low
> level connection manager, but it is private and don't seem to provide
> this precise information. state attribute, on the other hand, is the
> record type as defined in FastCGI protocol
> ( ), which I have not
> been able to determine if could be useful for this purpose or not;
> anyway, this is private too. Surely, Eddie's mastermind could provide
> more insight here.

This is actually an issue that has been bugging me a lot lately. When I
first started playing around with FastCGI I noticed that most of the web
servers out there do not adhere to the defined protocol very well. The
issue of killed connections is a perfect example. Ideally, there are two
ways that the web server can notify the FastCGI application of a killed
connection. The proper way, is by sending an FCGI_ABORT_REQUEST frame to
the application. This is rarely done. The improper way is for the socket
between the application and the web server to just be closed. This is
bad because the protocol allows for multiple requests to be handled on a
single socket. This only actually happens most of the time. On one of my
larger deployments I have noticed that stray dead requests accumulate at
a slow rate and never get destroyed. I have been thinking about
implementing some sort of internal timeout on Requests.

Long story short is this. If you want to have code executed when the
request is aborted, put it in the destructor of the derived Request
class. You unfortunately are not guaranteed to have the request object
actually destroyed. 
        Eddie Carle

reply via email to

[Prev in Thread] Current Thread [Next in Thread]