Re: Connection status

Thanks for your response. I'll try and explain what I'm trying to in a
better way.

mod_fastcgi -> accept queue -> ( application -> main_thread ->
internal/dedicated service queues -> dedicated thread pool -> tomcat)

The above sort of explains the request flow.
What the main thread does is, populates the dedicated service
queues(one queue per service) with the request object from
FCGX_Accept(). The configured/dedicated threads then pick up the
request object from the queue to forward the request to tomcat.

The problem is with handling timouts. The application accepts requests
which are internally queued within the application. mod_fastcgi may
abort the request after a specific time but the request is still
queued within the application which eventually gets executed. I need a
way(maybe a design change) to know if the request has already been
aborted by mod_fastcgi so I don't forward the same to tomcat.

> - 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.

This approach won't solve my problem because the requests are queued
internally only after an accept. Even if one of the request queues is
full, my main thread will have to block until this queue becomes empty
to be able to accept requests to other services. This reduces the
concurrency.

Is there a better design approach in solving this problem?

On Sun, Nov 9, 2008 at 8:48 PM, Rob Saccoccio <[email protected]> wrote:
> 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?
>
>
>
>