PRB: Blocking/Serialization When Using InProc Component (DLL) from ASP

ID: Q216580

The information in this article applies to:

Microsoft Visual Studio 6.0
Microsoft Internet Information Server version 4.0

SYMPTOMS

When calling an Active Server Page (ASP) page that instantiates an inproc component (DLL) from multiple clients, the user will see blocking/serialization; that is, all the clients have to wait for others to finish. If the inproc component is either Apartment or Multithreaded it should not behave this way.

CAUSE

The most common reasons for this behavior are listed below.

The IIS settings for your virtual directory may have the application debugging flags set. If application debugging is turned on, it will cause all requests to this virtual directory to be on a single thread.

Another common reason is that the different requests could run under the same Session ID and will, therefore, be serialized. This is usually the case if testing from multiple browser windows on a single machine.

Other reasons that can explain this behavior are mostly code related. Following are two code snipplets (Visual Basic and Visual C++) to be able to test and see if you are dealing with a coding issue (that is, the sample code works fine with no serialization), or with a configuration issue (that is, the sample code is showing the same behavior as described above).

RESOLUTION

Turn off application debugging at the virtual directory level:

To open MMC, click the Start menu, and point to Programs, Windows NT 4.0 Option Pack, and Microsoft Internet Information Server. Click Internet Service Manager.

Select the Virtual Directory, and select Properties.

In the lower half of the Virtual Directory properties (Application Settings pane), click Configuration.

From the Application Configuration properties select the App Debugging tab.

Clear both debugging check boxes.

STATUS

This behavior is by design.

MORE INFORMATION

Steps to Reproduce Behavior

Write the following class module in Visual Basic:


Private Declare Function GetCurrentThreadId Lib "kernel32" () As Long
Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)

Function ThreadWait(nSeconds As Long) As Long
    Sleep nSeconds * 1000
    ThreadWait = GetCurrentThreadId
End Function

Or Write the following code in Visual C++/ATL:


STDMETHODIMP CThreadTest::ThreadWait(int n, long *threadid)
{
    DWORD nthreadId;
    nthreadId = GetCurrentThreadId();
    Sleep (n * 1000);
    *threadid = nthreadId;
    return S_OK;
}

And the following IDL declaration:


    [id(1), helpstring("method ThreadWait")] HRESULT ThreadWait([in] int n, [out, retval] long* threadid);

Make sure your ClassID is named "ThreadWaitProject.ThreadTest." Compile the DLL.

Write the following Active Server Pages (ASP) script:


<%
  Dim objTest
  Set objTest = Server.CreateObject("ThreadWaitProject.ThreadTest")
  Response.Write "<TABLE border =1><TR><TD colspan=2 align=center><H3>InProc VB DLL<BR> ThreadWait 5 seconds</H3></TD></TR>"
  Response.Write "<TR><TD>StartTime: </TD><TD>" & Now & "</TD></TR>"
  Response.Write "<TR><TD>ThreadID: </TD><TD>" & objTest.ThreadWait(5) & "</TD></TR>"
  Response.Write "<TR><TD>EndtTime: </TD><TD>" & Now & "</TD></TR>"
  Response.write "<TR><TD>Session ID: </TD><TD>" & Session.SessionId & "</TD></TR></TABLE>"
  Set objTest = Nothing
%>

In order to succesfully test this ASP code, you will have to launch this ASP page from two or more different clients (machines)

NOTE: Do not run tests with multiple instances of Internet Explorer on a single machine.

In order to know if your test ran successfully, you should observe the following differences in the results on the different clients:

Start/End times should overlap

Thread IDs should be different

Session IDs should be different

Additional query words:

Keywords : kbActiveX kbASP kbATL kbIntl kbGrpASP kbDSupport
Version : WINDOWS:6.0; winnt:4.0
Platform : WINDOWS winnt
Issue type : kbprb