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
SYMPTOMSThis 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. CAUSEOn 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: - 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.
- The new worker thread exits.
- 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. WORKAROUNDTo 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 INFORMATIONThis 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: | Minor | Last Reviewed: | 5/30/2003 |
---|
Keywords: | kbprb KB813531 |
---|
|