olach
asked on
DCOM / COM+ 800700A4 error: "No more threads can be created in the system"
Our DCom App works fine during periods of 7 or more days but suddenly any object creation becomes to return the 800700A4 error.
No new Complus nor "DistributedCOM" records are added to the Event Viewer.
The server must to be rebooted (Shutting down the COM+ App Packet does not solves the problem).
The DLL is compiled in VFP 9.0 SP 2 and was working fine in a Windows Server 2003 Standard during a year.
The server is a HP Proliant ML350 G5 with one Intel Xeon 5320 and 6 Gb RAM.
We have several apps of this kind and we never reach before any kind of threads quantity limit.
Is possible that any kind of limit is being reached? If so, how to know the applicable limit? How to trace the moment this limit is reached?
May be this kind of limit related to a specific Build (RC, RC2, Trial, etc.)?
Thanks in advance;
Claudio
No new Complus nor "DistributedCOM" records are added to the Event Viewer.
The server must to be rebooted (Shutting down the COM+ App Packet does not solves the problem).
The DLL is compiled in VFP 9.0 SP 2 and was working fine in a Windows Server 2003 Standard during a year.
The server is a HP Proliant ML350 G5 with one Intel Xeon 5320 and 6 Gb RAM.
We have several apps of this kind and we never reach before any kind of threads quantity limit.
Is possible that any kind of limit is being reached? If so, how to know the applicable limit? How to trace the moment this limit is reached?
May be this kind of limit related to a specific Build (RC, RC2, Trial, etc.)?
Thanks in advance;
Claudio
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Yes, is not so easy to locate our threads at Reliability and Performance Monitor nor ProcessExplorer.
Anyway now we have more elements to think about the problem is related to the system general configuration, because the maximum object coexistence not surpasses 200 elements and if the first limit shown is 2000 threads and this limit is really being reached, the OS must be creating lots of threads by its own (OK, is WS, but we never showed this limit before).
Normally we stop a quantity of services not in use, but we must to do a new analysis from this point of view and considering the new ones in WS 2008 x64. May be Reliability and Performance Monitor will be more useful for this.
Thanks a lot, mpfister.
Anyway now we have more elements to think about the problem is related to the system general configuration, because the maximum object coexistence not surpasses 200 elements and if the first limit shown is 2000 threads and this limit is really being reached, the OS must be creating lots of threads by its own (OK, is WS, but we never showed this limit before).
Normally we stop a quantity of services not in use, but we must to do a new analysis from this point of view and considering the new ones in WS 2008 x64. May be Reliability and Performance Monitor will be more useful for this.
Thanks a lot, mpfister.
ASKER
1st: It was impossible for us to define a specific counter for our components library due to it is not listed in the instances of selected object box.
2nd: We do not know about any red zone o maximum value related to threads quantity.
So, this trace method is not very useful for us, in this case and I still thinking that the very important issue is to know if we can be really reaching certain limit related to threads quantity, specific to this Windows Server version, and how is that limit defined.
Note that max memory usage seen, for all server charge, was 1.5 GB and the server has 6 GB.
Anyway, Thanks mpfister.