CODEWITHSUNDEEP
iis-7reverse-proxy
Hyddan
Hyddan

Reputation: 1337

IIS ARR (edge) cache (reverse proxy) - Upstream connection timeout issue

I am looking to use the IIS Application Request Routing as a reverse proxy cache. I've looked at several different options and come to the conclusion that it fits my needs the best. However, I've run into a sort of a dead end and could really use some input from someone who has more experience with the ARR module.

I have the following setup:

The use case is such that the edge servers will receive byte range requests and as it serves the content to the end user it will cache it (first 60 sec in memory cache, then write it to the RAM disk). So far everything is working correctly but when the next end user starts requesting the same byte ranges (that are now in the cache) I'm starting so see some weird behaviour between the IIS edges and the nginx origins: Upon the first byte range request (by the second end user) the IIS server opens a connection to the nginx origin which it does not use because it already has the requested segments in the cache. Since the connection isn't being used it's eventually closed by nginx due to a timeout (60 seconds). In the mean time the second end user is still requesting segments of the file that are in the cache. Then, and this is where the issue occurs, the second end user gets to a point in the file which is not in the cache. The behaviour I would expect from IIS here (being that keep-alive is disabled) is that it would open up a new connection to the origin and start fetching the part of the file that isn't in the cache. The behaviour I'm seeing however is that IIS tries to reuse the same connection it opened up in the beginning of the request (without realizing that it's been dropped by the origin). I've used the "Failed request tracing" to verify this as well and the result of that is that the IIS doesn't get an expected reply from the origin (since the connection no longer exists) and then, in turn, returns a 502.3 to the end user.

I've verified that increasing the connection timeout on the origins will "solve" the problem, but that is not really a viable solution as I would basically have to set an infinite timeout which may cause a whole new set of problems on the origin side. Is there any way of controlling how IIS handles this upstream connection (i.e. force it to open a new connection when it actually needs data from the origin, or to have it realize that the origin closed the connection)?

Upvotes: 3

Views: 2144

Answers (1)

Hyddan
Hyddan

Reputation: 1337

For anyone who may be experiencing the same issue; after some back and forth with Microsoft this actually turned out to be a bug in the ARR module which will get addressed in an upcoming release.

Upvotes: 1

Related Questions