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

Skip to first unread message

David Notik

Jan 26, 2016, 9:06:37 PM1/26/16
to Dart Server-side and Cloud Development
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:

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.


Thank you so much!


David Notik

Jan 27, 2016, 5:09:05 PM1/27/16
to Dart Server-side and Cloud Development
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 {
.Response response = await this.staticHandler(request);
if (request.protocolVersion == '1.1') {
= 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?

Reply all
Reply to author
0 new messages