On 10/13/2008 11:46 AM, Jess Holle wrote: > Ruediger Pluem wrote: >> On 10/13/2008 12:50 AM, Jess Holle wrote: >> >>> Perhaps I misunderstand things here, but isn't this connection timeout >>> setting used for more than just the timing out the initial formation of >>> the connection? It would seem that logical that there would be a >>> connection timeout for forming the initial connection and another for >>> timeouts of responses, etc, but I had understood this was not the >>> case. We currently have connection timeout set very, very large as >>> otherwise >>> we got timeouts when the backend URL was something very computationally >>> intensive that took a long time to respond with data (e.g. a good number >>> of minutes). That should seemingly be distinct from an initial >>> connection timeout, but my understanding was that it is not. >>> >>> Am I just confused here? >>> >> No you are not. The next 2.2.x release will contain the parameter >> connectiontimeout >> where you can set *just* the connection timeout. The other parameter >> you are referring >> to is timeout. It will keep its meaning and will be used as a >> connection timeout >> if connectiontimeout is not set. >> > Ah, so we additionally need something like Matt Stevenson's patch (or > just change connection timeout to be a float or double rather than > changing its units) to allow connection timeouts of much less than 1 > second (e.g. 0.125 seconds) to address my Windows issue with slow > connection rejection -- and that's /if/ Windows consistently connects in > less than that timeframe when it is going to connect. > > Right?
Not exactly. I would prefer to fix the basic issue with Windows. If we need to support milliseconds for connection timeouts seems to be another story for me. Can some of the Windows gurus come to the rescue to either confirm and explain why it takes that long for connect to return after trying to connect to a closed port (on the same machine !!!) or if this must be a local issue on a specific machine. Regards Rüdiger
