Anil,
Thanks, I have used the ARR freb tracing walkthrough before, and I agree it is very helpful for isolating a specific request.
However, the issue in my inquiry was was if ARR automatically retried a failed request to another node on the server farm so that the request failure would not go all the way back to the end user . Looking at the logs in more detail, I can now see that this is not happening. Has the ARR team ever considered a retry mechanism?
Perhaps you could also shed some light on why the HTTP response codes are altered by ARR. In the example below, a 500 response from a sever farm node was converted to a 400 (bad request) response to the client.
(NODE) 2009-10-21 22:41:03 IP GET /App/Page.aspx Param1=xxx&X-ARR-LOG-ID=xxx 443 - OriginIP Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0) 200 0 0 468
(ARR ) 2009-10-21 22:41:05 IP GET /App/Page.aspx Param1=xxx&X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=xxx 443 - OriginIP Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0) 200 0 0 1684
(NODE) 2009-10-21 22:44:26 IP POST /App/Page.asp Param1=xxx&X-ARR-LOG-ID=xxx 443 - OriginIP Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0) 500 0 64 128107
(ARR ) 2009-10-21 22:44:26 IP POST /App/Page.aspx Param1=xxx&X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=xxx 443 - OriginIP Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0) 400 0 64 128108
Thanks for your feedback.
Jim