[omniORB] deadlock with distributed callback application

[Duncan Grisby]

On Wednesday 2 May, Lars Immisch wrote:

> In essence, I have several servants that call back into a single client.
> When I start two operations, and they complete simultaneously, the first
> server blocks on the invocation of the completion forever. The client
> interestingly also blocks - it seems to get stuck on a _is_a which comes
> just before the completion.

The problem is that you haven't activated the root POA in the client
program, so when the callback comes in, the call is blocked waiting
for POA activation.

The fact that the client also blocks in _is_a on its second call is
due to the way omniORB handles threads at the moment. omniORB uses one
thread per TCP connection. Normally this means that for a client to
invoke two operations on a server concurrently, the client must have
two threads, and open two TCP connections. However, with oneway
operations, a second request can be sent on the same connection,
before the first has finished.

So, what's happening is that on the first call from the client to the
server, the client opens a connection and the server starts a thread.
That thread does a call back to the client, which blocks forever due
to the inactive POA. Now, the client is still running, and sends
another request over the same TCP connection. The thread servicing
that connection is blocked waiting for the callback reply, so the
client is now also blocked for ever.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --