Bi-Directional Communication Deadlock in the client callback

JGarvey

I'm using Bi-Directional communication and am running into a deadlock issue that does not seem to be covered in the documentation. I'm wondering if you can help me understand why the deadlock exists and what the possible solutions would be.

I have a service, A, which connects to service B. A bi-directional connection is set up so that B can send notifications to A using a oneway proxy.

I understand that when A receives the oneway notification from B that a client thread is used to call the handler. In the handler, A makes a request to B. B processes the request and sends the response, but A never receives the response. I believe this is because a second client thread is needed to receive the response from A and allow the first client thread to continue. (If I increase A's client thread pool, my deadlock problem goes away.)

Am I correct? I do not understand why a second client thread is needed. Why can't the client thread that is making the request to B be used to receive the response? Is it true that any thread can be used to send a request, but only a client (because it is bi-dir) thread can be used to receive the response, even if you are not using AMI?

Possible Solutions:
I know that scheduling a timer in the handler so that the timer could make the request to B works. And I assume that if I change the request to use AMI that the response could be processed. Are there any other possible solutions other than increasing the client thread pool size?

Thanks,
Jesse

mes

Hi Jesse,

Welcome to the forum!

Am I correct? I do not understand why a second client thread is needed. Why can't the client thread that is making the request to B be used to receive the response?

You're correct. With your current implementation, adding another thread to the client thread pool is necessary.

Ice does not use an application thread to process replies (even if the "application thread" is a thread from an Ice thread pool) because there's no guarantee that the next reply off the wire will be the one that the application is awaiting, and therefore the application could be delayed unnecessarily while the thread is dispatching the reply of a different request.

Is it true that any thread can be used to send a request, but only a client (because it is bi-dir) thread can be used to receive the response, even if you are not using AMI?

Yes, that is true.

Your usage scenario is what we call a "nested invocation". Here's a copy of a relevant paragraph from this section of the Ice manual:

As another example, consider a client that makes a nested invocation from an AMI callback object using the default thread pool configuration. The (one and only) thread in the client thread pool receives the reply to the asynchronous request and invokes its callback object. If the callback object in turn makes a nested twoway invocation, a deadlock occurs because no more threads are available in the client thread pool to process the reply to the nested invocation. The solutions are similar to some of those presented for Figure 32.5: increase the maximum size of the client thread pool, use a oneway invocation, or call the nested invocation using AMI.

Let us know if you have more questions.

Regards,
Mark