Microsoft KB Archive/216580

= Blocking/serialization when using InProc component (DLL) from ASP =

Article ID: 216580

Article Last Modified on 3/31/2006

-

APPLIES TO


 * Microsoft Internet Information Server 4.0
 * Microsoft Visual Basic 6.0 Professional Edition
 * Microsoft Visual Basic 6.0 Enterprise Edition
 * Microsoft Visual C++ 6.0 Professional Edition

-



This article was previously published under Q216580



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:


 * 1) 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.
 * 2) Select the Virtual Directory, and select Properties.
 * 3) In the lower half of the Virtual Directory properties (Application Settings pane), click Configuration.
 * 4) On the App Debugging tab, click to clear the following debugging check boxes:
 * 5) * Enable ASP server-side script debugging
 * 6) * Enable ASP client-side script debugging



STATUS
This behavior is by design.



Steps to reproduce the 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 " " 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

Keywords: kbintldev kbprb KB216580

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.