views:

32

answers:

1

I have an application that sends requests to an out of proc COM server whom handles the requests and sends them back to the requesting application.

The client application is really in control of the start-stop of this Out-of-Proc COM server and determines its lifetime so to say.

Because this application has many hundreds of requests at any given time, it mostly has at least 4 of the same COM servers to handle these requests.

The problem is that sometimes this COM servers gets hung up handling a request, which is caught by the requesting application, whom kills the out of proc COM server. This however does not always happen.

What sometimes happens is that the client application requests a COM server kill, which results in the client releasing all references to the COM Server, but the COM server ends up just using 25% of the CPU and just never dies. It seems it just hangs and uses CPU constantly.

The client has mechanism to attempt to kill the COM Server process forcibly if it fails to die, however even that does not seem to work in the cases where the COM server gets into the CPU usage and just hangs.

Has anybody experienced something similar or has some advice on how one could resolve a situation like this?

+1  A: 

You need to design all calls in the COM server in such way that they all end in some reasonably short time. Once a new call arrives from the client COM spawns a separate thread and dispatches a call onto that thread. There's no reliable way to interrupt the call - the call needs to end on itself (just return). You achieve this by designing your algorithm appropriately.

sharptooth
So you say that the COM proc hang could be because a call was interrupted and now cannot end itself properly, as the client has already disconnected?
Tony
@Tony: No, the out-proc server hangs because the call passed control to some code that didn't return. You can try this yourself - add an endless loop into any COM method implementation and call that method from a client. You can kill the client, but the server will be running at least for a long period of time and I suppose that it will just run forever.
sharptooth
OK, so all COM calls really have to return before you can kill the out of proc server. Thing is that I haven't seen a place where an endless loop could occur in my proc server, so even if there isn't such a loop, and the call doesn't return, we have a problem?
Tony
All COM calls need to return before COM can stop the server. You can attempt to kill the process at any time but you guess what the consequences will be. Any time the call implementation goes into something that doesn't return promptly you have a problem.
sharptooth
So if you called TerminateProcess on this COM Server from the client, would it kill?
Tony
@Tony: usually yes, as with any other processes. You will need to have sufficient privilidges for that however. If you don't start the process yourself, but instead rely on COM for that you might not have sufficient privilidges.
sharptooth
@sharptooth: Thanx a lot for your help. One more question. Can we get the privileges to kill the proc even if it was started by COM??
Tony
@Tony: It would depend on many factors - you better not rely on that. Your best bet is to design your code appropriately.
sharptooth