[FASTCGI] Connection status

Rob Saccoccio robs at fastcgi.com
Sun Nov 9 10:18:01 EST 2008


If understand you correctly, I don't think that this can be done given the
way that mod_fastcgi (and most socket based client-server applications) are
written.  And IIRC, this is area of OS code (listen queue and connect()
handling) that varies quite a bit from platform to platform. 

mod_fastcgi connects to the application and immediately queues data for the
connection.  It's not until sometime later that the application will accept
the connection and start reading the data.  The OS provides the queue of
pending connections (the listen/accept queue) and both the client and server
side can hold buffered data.

You haven't said why it is you want to do this (or why you're using this
unusual architecture), but here are some ideas that might help:

- Read the entire request before calling into tomcat. Unless you're
uploading, incoming requests are generally very small and can easily fit a
buffer.

- Use non-blocking connects from mod_fastcgi (set appConnectTimeout to a
non-zero value).  This will cause mod_fastcgi to not enqueue the request if
the timeout expires before the request is given a slot in your applications
listen queue.  

- Reduce the listen queue depth in your application to 0 or 1 and use
non-blocking connects from mod_fastcgi.  This will increase request latency
though.

- Use longer timeouts on the mod_fastcgi side to reduce the likelihood.

Rob


> I'm implementing a scenario in which I'm starting up tomcat using a
> fastcgi application.
> I use a queue to stack up requests which gets served by a threadpool
> in the application
> that forwards the request to tomcat.
> 
> I have a problem when it comes to handling timeout conditions. What's
> happening is that
> mod_fastcgi times out the request when it doesn't get a response from
> tomcat. I need a
> way of checking if the request that is queued is already timed out
> before forwarding the request
> to tomcat. I looked around a bit and didn't find a way to do this.
> 
> Any ideas on this anyone?





More information about the FastCGI-developers mailing list