Engels Rajangam

Moving to MS IDC, India

2008-05-28T02:54:00Z

Recently I decided to move to India for personal reasons. So I joined Microsoft India Development Center at Hyderabad as a Program Manager.

I am still traveling to undergo trainings for my new role, but will eventually settle down in Hyderabad (July 2008?).

System.Net: Intial auto proxy delay resulting in requests failing with "the operation has timed out" exception

2008-02-13T17:43:00Z

Recently I came across an interesting issue.

A windows service application (originally developed with VS2003/.NET Framework 1.1) is designed to make several HTTP(s) requests in multiple threads simultaneously. With upgrading to VS2008 and recompiling the code, the app started seeing several requests failing with "The operation has timed out" exceptions.

Taking a System.Net trace (http://msdn2.microsoft.com/en-us/library/ty48b824(VS.80).aspx) showed several threads failing as follows.

System.Net Verbose: 0 : [6044] WebRequest::Create(http://www.someserver.com/)

ProcessId=9616

DateTime=2008-02-08T21:45:52.3396033Z

System.Net Verbose: 0 : [6044] HttpWebRequest#38203409::HttpWebRequest(http://www.someserver.com/)

ProcessId=9616

DateTime=2008-02-08T21:45:52.3396033Z

System.Net Verbose: 0 : [6044] Exiting HttpWebRequest#38203409::HttpWebRequest()

ProcessId=9616

DateTime=2008-02-08T21:45:52.3396033Z

System.Net Verbose: 0 : [6044] Exiting WebRequest::Create() -> HttpWebRequest#38203409

ProcessId=9616

DateTime=2008-02-08T21:45:52.3396033Z

System.Net Verbose: 0 : [6044] HttpWebRequest#38203409::GetResponse()

ProcessId=9616

DateTime=2008-02-08T21:45:52.4021029Z

System.Net Information: 0 : [6044] Associating HttpWebRequest#38203409 with ServicePoint#58391824

ProcessId=9616

DateTime=2008-02-08T21:46:12.4957243Z

System.Net Error: 0 : [6044] Exception in the HttpWebRequest#38203409::EndGetResponse - The operation has timed out

ProcessId=9616

DateTime=2008-02-08T21:46:12.4957243Z

From the above we can see that the request failed almost immediately with the exception. Taking a network trace I confirmed that the specific request above was not sent over the wire.

Checking the trace at the beginning I could see that the application started making numerous requests. However before these requests were sent on wire, .NET Framework was trying to detect auto proxy for the urls submitted. This took about 5-7 seconds, by which time there were numerous requests in queue. The timeout set for each request was 20 seconds, however most of them started failing as shown above.

Since auto proxy detection was added only from 2.0 and above, the application did not see the same problem with 1.1 .NET Framework.

In this case, the following were the possible solutions.

1. Disabling auto proxy and configure static proxy in the app.config for the application.
2. Change code to wait for the the first request to complete (including auto proxy). Then start sending the requests from the application.

In our case, the issue was resolved by disabling auto proxy and setting static proxy in app.config. More information on doing this is available at http://msdn2.microsoft.com/en-us/library/sa91de1e(VS.80).aspx

Response accumulating Web Filter running into performance issues...

2006-08-21T20:03:00Z

I have come across this specific issue couple of times now.

A response accumulating web filter (such as WebResponseModifier with the ISA 2004 SDK), does the following.

1. Accumulates resoponse to client in SF_NOTIFY_SEND_RAW_DATA notification.
2. In SF_NOTIFY_END_OF_REQUEST notification, the filter writes modified or unmodified response to client using WriteClient.
3. WriteClient takes a long time to complete. This is often seen when WriteClient is used to write HTTP status line and headers.

Note: MSDN docs on WriteClient confirm that web filters may run into performance issues with WriteClient. Please refer the following for more information.

WriteClient: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/isasdk/isa/writeclient.asp
Best Practices: http://msdn.microsoft.com/library/en-us/isasdk/isa/best_practices_for_web_filters.asp?frame=true

In IIS ISAPI, it is recommended NOT to use WriteClient for writing status line and headers but to use ServerSupportFunction. This is because IIS does not detect that the response to client includes headers (which may result in IIS not correcting / erroring out if the response HTTP message is not formatted correct), if WriteClient was used.

In a similar way, the above ISA WriteClient performance issue can be resolved by using ServerSupportFunction instead. This of course adds additional couple of lines of code to your solution, however this is a cleaner and optimal way of writing response to client.

More info on ServerSupportFunction in ISA SDK is available at
http://msdn.microsoft.com/library/en-us/isasdk/isa/serversupportfunction.asp?frame=true

Example code snippet:

char szHeaders [1024] = "Cache-Control: no-cache, no-store\r\nContent-Type: text/html; charset=utf-8\r\nContent-Length: 228\r\nServer: Microsoft-IIS/6.0\r\n\r\n";

pfc->ServerSupportFunction(pfc, SF_REQ_SEND_RESPONSE_HEADER, (PVOID) "200 OK", (ULONG_PTR) szHeaders, NULL);

As you can see szHeaders is for adding any additional headers to the response.

Note: Do not add \r\n at the end of 200 OK (status).

Planning to add info on "Underlying connection was closed" errors.

2005-11-29T19:15:00Z

Planning to add information on "Underlying connection was closed" errors, until a KB article is written.

This is done. You can read the article here http://blogs.msdn.com/engelsr/articles/497902.aspx