Article ID: 301512
Article Last Modified on 12/5/2007
APPLIES TO
- Microsoft COM+ 1.0
- Microsoft COM+ 1.5
This article was previously published under Q301512
SYMPTOMS
When a client makes Distributed Component Object Model (DCOM) calls to a COM+ server application, you may run out of Transmission Control Protocol (TCP) ports if you are using dynamic cloaking. Remote Procedure Call (RPC) uses a new server binding handle (and thus one new "established" TCP connection) for each user's security context.
With reference to the frequency of the calls, TCP connections can grow quickly to consume all available client ports above 1024.
If you shut down the COM+ server application and restart it, you can free up client ports to provide relief; however, the problem recurs over time.
RESOLUTION
The TCP connections are closed if you release all the remote objects that the specific COM+ server application supplies. The state changes from ESTABLISHED to TIME_WAIT only after several minutes from the latest Release call on the local proxies.
In certain scenarios, where it is not possible to release the remote objects, if the calls are made with different security contexts while dynamic cloaking is active, you must enable periodic RPC cleanup of the idle bindings to reduce the growing of TCP connections, given the high number of established TCP connections that is required. To achieve this, you must call the RPC RpcMgmtEnableIdleCleanup function at beginning of the client's code.
In addition, you may need to increase the available ephemeral ports on the client. For additional information, click the article number below to view the article in the Microsoft Knowledge Base:
196271 Unable to Connect from TCP Ports Above 5000
To improve the scalability of your distributed application, Microsoft recommends that you avoid performing DCOM outgoing calls with different security contexts. In situations where this is not possible, consider periodically releasing your remote COM+ objects. If neither option is possible, call RpcMgmtEnableIdleCleanup at beginning of the client's code.
MORE INFORMATION
This behavior is very similar to the problem that is described in the following Microsoft Knowledge Base article:
290512 FIX: COM+ Applications Consume All Available Client Ports Between 1024 and 5000 and Cause High CPU Utilization
However, the problem that is described in this article is related to the TCP connections that are used for COM+ proxy/stub communications.
When you encounter this problem, if you use the "netstat -n" command to examine the connections between the two computers, the output may show that all of the ephemeral ports (all ports between 1024 and 5000) on the DCOM client have been used and are in the ESTABLISHED state with a specific server's port (one above 1024). For example:
TCP 10.202.250.46:1025 10.202.102.122:2008 ESTABLISHED
TCP 10.202.250.46:1026 10.202.102.122:2008 ESTABLISHED
............
until
............
TCP 10.202.250.46:4997 10.202.102.122:2008 ESTABLISHED
TCP 10.202.250.46:4998 10.202.102.122:2008 ESTABLISHED
TCP 10.202.250.46:4999 10.202.102.122:2008 ESTABLISHED
TCP 10.202.250.46:5000 10.202.102.122:2008 ESTABLISHED
All of those TCP connections are related to COM+ proxy/stub communications. DCOM cannot recycle one of them if a thread that impersonates a new user (with dynamic cloaking active) makes a call. For example, if the client is an Internet Server Application Programming Interface (ISAPI) extension that runs on Microsoft Internet Information Server (IIS), the calls are made with the impersonation token that IIS obtained when it performed user authentication (for example, using basic authentication). In that scenario, each new IIS user token requires one or more new RPC bindings (and thus one or more new "established" TCP connections). Moreover, the number of IIS user tokens depends on the IIS token cache. For additional information about the UserTokenTTL parameter, click the article number below to view the article in the Microsoft Knowledge Base:
152526 Changing the Default Interval for User Tokens in IIS
DCOM does not release TCP connections until all objects in the remote COM+ server application are released. In this way, it is possible to recycle an RPC binding for the outgoing calls if the security context, transport, host, and endpoint are the same. If you want to enable periodic RPC cleanup of the idle bindings, call RpcMgmtEnableIdleCleanup at the beginning of the client's code. However, be aware of the overhead that is necessary to re-create new, authenticated RPC bindings for the next calls.
Keywords: kbrpc kbdcom kbprb kbclientserver kbscalability KB301512
