PRB: Established HTTP Connections Are Reset Intermittently (813531)



The information in this article applies to:

  • Microsoft Internet Information Server 5.0
  • Microsoft Internet Information Server 4.0

SYMPTOMS

This problem occurs in the following scenario:
  1. You create a new worker thread, and then HSE_STATUS_PENDING is returned in the HttpExtensionProc function.
  2. 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.

MORE INFORMATION

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

REFERENCES

For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

185518 HOWTO: Implement Worker Threads Using MFC ISAPI Extension

197728 Creating a Thread Pool for MFC-Based ISAPI Extensions


Modification Type:MinorLast Reviewed:5/30/2003
Keywords:kbprb KB813531