Many file descriptors left open on my (Shelf) Dart server

[David Notik]

I had this issue where my main Dart server was not responding to new requests (requests would time out). Some investigation, and it seemed open file handles were at 1024, which is my GCE instance's ulimit -n. See: https://gist.github.com/davenotik/f0cce2ba760e15a05fb1

It seems there are two issues there: a) the index.html that's served is repeated many times (not closed?) and b) there are many connections left in a CLOSE_WAIT state (and tons from that damn aspen site). It seems we get one of those connections whenever a new client connects to the server (e.g. I hit my app in a browser and I saw file descriptors with my internet provider in the host).

Ideas why these connections aren't closing? I'm serving w/ Shelf – just saw the version on prod is 0.6.3+1 and I should probably upgrade.

Related, I noticed that I had to do a response.drain() in a certain instance to clear the connections resulting from some http PATCHes to Firebase's REST API. Otherwise they'd stick around seemingly for a long time.

Insights?

Thank you so much!

--D

[David Notik]

Hi again.

I believe this had to do with my server attempting to apply 'Transfer-Encoding":"chunked" headers to gzip where the client only supported HTTP 1.0, thus causing an exception...

HttpException: Trying to set 'Transfer-Encoding: Chunked' on HTTP 1.0 headers

...which then suspended the code so that the connection was never closed.

I added a if (request.protocolVersion == '1.1') condition. I believe the issue went away – so far it looks good.

Future<shelf.Response> _handleFile(shelf.Request request) async {
 shelf.Response response = await this.staticHandler(request);
 if (request.protocolVersion == '1.1') {
   response = response.change(headers: {'Transfer-Encoding': 'chunked'});
 }
 return response;
}

Can anyone confirm that such an exception would in fact prevent the connection from closing, resulting in a CLOSE_WAIT?

--D