IIS 7 and Above
Application Request Routing (ARR)
ARR URL-Rewrite timing out for larger posts
Last post May 05, 2020 09:14 AM by Yuk Ding
May 04, 2020 01:16 PM|Dougal123|LINK
Hi, we have 'webhooks' coming into our server from an external client, and we use a rewrite rule to forward them on to the appropriate internal server on our network.
The external client imposes a 10-second timeout within which they want us to respond 'OK'
All works well for small webhooks, but as soon as they get a bit larger (80K+) our url rewrite server seems to 'pause' for more than 10 seconds without doing anything, at which point the external client breaks the connection.
So a small webhook comes in from the external client, our URL rewrite server forwards it to the internal server, that responds 'OK', and the response is returned to the client.
But a larger one gets as far as the URL rewrite server, which then pauses for more than 10 seconds without forwarding it to the internal server (there is no trace of it on the internal server's IIS log), then the client times out.
Here's some tracing:
Lots of GENERAL_REQUEST_ENTITY_START/END, ARR_REQUEST_ENTITY_START/ENDs, NOTIFY_MODULE_COMPLETION etc., as chunks of the JSON message are read in. This all takes a very little time, 0-20ms per chunk at maximum.
Then we get to ARR_RESPONSE_HEADERS_START (0ms)
Then "MODULE SET RESPONSE ERROR STATUS" - 9937ms, and that's the 10 seconds gone...
The error status details are:
ErrorCode:An existing connection was forcibly closed by the remote host.
So, how do I find out where those 9937ms are going?
If my internal server's IIS log shows nothing, is it a safe assumption that the URL Rewrite server is the one 'sitting on' the message?
Any help gratefully received...
(Windows Server 2012 Standard, IIS 8.0, ARR version 3)
May 05, 2020 09:14 AM|Yuk Ding|LINK
I would recommend you to capture WINHTTP and WININET,http.sys etl log. If there is any IIS limit reached, the limit will be logged. As far as I know there is no request limit in URL rewrite module.
So I think capture ETL log is the only way to find the root cause.
If you have no idea about how to analyze these logs, you can create a support ticket to involve professional support engineer.