Microsoft KB Archive/813531

= PRB: Established HTTP Connections Are Reset Intermittently =

Article ID: 813531

Article Last Modified on 5/30/2003

-

APPLIES TO


 * Microsoft Internet Information Services 5.0
 * Microsoft Internet Information Server 4.0

-



SYMPTOMS
This problem occurs in the following scenario:  You create a new worker thread, and then HSE_STATUS_PENDING is returned in the HttpExtensionProc function.  After the new worker thread function performs some processes, it calls ServerSupportFunction by using HSE_REQ_DONE_WITH_SESSION, and then the new thread exits. For example: pECB->ServerSupportFunction(pECB->ConnID, HSE_REQ_DONE_WITH_SESSION, NULL, NULL, NULL); return 0; The following Knowledge Base article includes a sample MFC implementation:

185518 HOWTO: Implement Worker Threads Using MFC ISAPI Extension



When this type of ISAPI extension is under heavy load (when there are many concurrent requests to the extension), the IIS server resets some established HTTP connections intermittently.



CAUSE
On the main function thread (HttpExtensionProc), the ISAPI creates another worker thread, and then returns HSE_STATUS_PENDING. After the new worker thread performs some processing tasks, it uses ServerSupportFunction to notify the Internet Information Services (IIS) server that the processing is completed, and then exits. The following steps describe this in greater detail:
 * 1) The new worker thread calls ServerSupportFunction by using HSE_REQ_DONE_WITH_SESSION. This notifies the IIS server that all processing has been completed. Therefore, the server can prepare for a new processing job. The IIS server closes the socket that was connected to the client, and then opens a new socket to accept later connection requests.
 * 2) The new worker thread exits.
 * 3) The IIS server detects that the worker thread has exited, and then the server closes the open socket that was created by the terminated thread.

Typically, the elapsed time between step 1 and step 2, or between step 2 and step 3, is very short. However, if a client connects during the time between step 1 and step 2, or between step 2 and step 3, the connection is reset when the thread exits or when the IIS server closes the socket.



WORKAROUND
To work around this problem, do one of the following:  Use a thread pool in the ISAPI extension so that the worker threads do not exit. For additional information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:

197728 Creating a Thread Pool for MFC-Based ISAPI Extensions

This is the recommended approach when you must create a separate thread in the ISAPI extension.  Send a keepalive request to the ISAPI extension from a client, and then use a keepalive flag when you call ServerSupportFunction by using HSE_REQ_DONE_WITH_SESSION. For example: DWORD dwState = HSE_STATUS_SUCCESS_AND_KEEP_CONN; pECB->ServerSupportFunction(pECB->ConnID, HSE_REQ_DONE_WITH_SESSION, &dwState, NULL, 0); When you use this workaround, the IIS server does not close each socket and then open a new one. It maintains the existing connection. 



STATUS
This behavior is by design.

<div class="moreinformation_section">

MORE INFORMATION
This is the correct behavior of the ATQ thread model in IIS 4.0 and IIS 5.0.

<div class="references_section">