IISNode responds with HTTP500.1013 after subsequent requests with long processing time (around > 5 seconds)

[j-windsor]

Repro Steps

Using Azure AppService with Node v8.0.0, IISNode v0.2.21
Using default settings in IISNode, Web.config. No iisnode.yml

Producer (server.js)

var http = require('http');
http.createServer(function (req, res) {
    setTimeout(() => {
        res.writeHead(200, {'Content-Type': 'text/html'});
        res.write('hi');
        res.end();
    }, 6000);
}).listen(process.env.PORT);

Consumer (tester.py)

import requests
import time

for i in range(0, 10):
    t0 = time.time()
    r = requests.get('https://***.azurewebsites.net/hi')
    t1 = time.time()
    print(str(r.status_code) + " in " + str(t1-t0) + "ms")

Output

200 in 6.27462887764ms
500 in 5.32504105568ms
200 in 6.14366197586ms
500 in 5.32526397705ms
200 in 6.14505696297ms
500 in 5.32463908195ms
200 in 6.14349889755ms
500 in 5.32335090637ms
200 in 6.34911417961ms
500 in 5.324187994ms

[Kannaj]

Did you by any chance manage to find a solution for this? been getting this error for quite a while

Also , how does one get to find the IISNode version via cmd/powershell?

[j-windsor]

Still waiting for someone (@tjanczuk ) to respond. No idea how to fix this still. Sorry :(

[j-windsor]

Found a fix! Updating version of node to 8.9.4 seems to do the trick for me.

[srowan]

I'm getting something similar on 8.11.1 ... seemingly random HTTP500.1013 errors. Much more rare than your example shows however, and very difficult to reproduce.

[abondoa]

We are also seeing it on node: v10.14.1. As mentioned by @srowan we also get it quite rarely - around ~1/1000 requests.

Additional notes:
We have logging setup though application insights, which logs all requests and their status codes, except for those few 500.1013, which are not logged. They are still caught in the IIS log though.
That leads me to believe that my node process is killed before the request finishes or at least the request fails in such a way that the logging middleware is somehow circumvented (or my logging framework is broken). Subsequent request are handled just fine, even though they happen seconds after the 500-failure - not enough time for our node process to come back up if it was completely down.

[afuller611-animas]

@abondoa Did you or anyone else ever find a fix for this? We noticed a very similar thing with logging.

[gregogalante]

@abondoa Did you find a solution for the problem?

[abondoa]

@afuller611-animas @gregogalante I ended up setting the keepAliveTimeout to 0, which essentially turns off the keep-alive timeout (might not be recommended in all cases). The cause of it is described in nodejs/node#13391