http server hangs up for 2 mins and then serves

[Mark Hahn]

I have a weird situation where the http server doesn't do the callback
with a request object for precisely 2 minutes and then does the
callback as if nothing was wrong. This happens in a precise location
in my app where I'm requesting about 8 pages/images and one of those 8
has the problem. At different times it is a different one of the 8
requests that has the hangup.

I've been tearing my hair out trying to see what I do differently at
this point in my app. I've done packet sniffing etc but everything
looks normal. The only thing I can think of doing from here is
reducing my code down to simpler and simpler cases but that is going
to be quite painful since my app is large and complex.

I know that 2 mins of inactivity on an http connection causes a
timeout. But if my request was timing out then I shouldn't get the
good results at the end, right? Is it possible for one bogus request
to hold up another until the bogus one times out?

Anyone seen anything like this before? Any ideas as to what might be
causing this?
Thanks in advance.

[Jann Horn]

Am Freitag, den 04.03.2011, 12:51 -0800 schrieb Mark Hahn:
> I know that 2 mins of inactivity on an http connection causes a
> timeout. But if my request was timing out then I shouldn't get the
> good results at the end, right? Is it possible for one bogus request
> to hold up another until the bogus one times out?

Maybe you don't end() the response and the client renders the part it
already has when the connection times out? Or it's from the browser
cache?

Jann

[Mark Hahn]

> > Maybe you don't end() the response

It is kind of hard to end the response when I have never gotten the
http server callback with the request and response objects in the
first place.

However, I think you are right, but the problem is not in my code. I
found out it happens when I send a multi-part POST request with no
part. Apparently there is a bug in the Formidable module that causes
it to hang waiting on a part that never comes. When that connection
times out then the original request connection is processed.

Handling this no-part situation is necessary because the browsers send
it out. I tested in all browsers.

Does anyone know a good alternative to Formidable? I'm already not
running on the master fork of Formidable because it doesn't support
radio input elements when you are using the convenience feature of
having it give you the fields in an object (which I consider
mandatory).

>  signature.asc
> < 1KViewDownload

[Joran Greef]

I have had the same problem in the past. It could happen for example
if you're setting a Connection: keep-alive header and then pausing a
request and forgetting to resume it. That could back up subsequent
requests sharing the same connection. There's also a problem that's
possibly related being discussed over here:
http://groups.google.com/group/nodejs-dev/browse_thread/thread/1dd6d3dbd138d580