[omniORB] Distributed deadlock with mixed client/server apps

[Duncan Grisby]

On Wednesday 14 November, Patrick Hartling wrote:

[...]
> The call by ObserverImpl to getValue() in Subject blocks.  As far as I 
> have been able to determine, the problem is on the C++ side.  I have 
> tried three different Java ORBs (Java IDL in JDK 1.4, OpenORB 1.2.0, and 
> ORBacus 4.1.0), and all give exactly the same behavior.  I am still 
> compiling ORBacus 4.1.0 for C++ to try it in place of omniORB.

It isn't clear from your diagram, but I assume that the call to
getValue() is recursive -- i.e. it happens before the call to
setValue() has returned. There are two ways a client can choose to
perform this kind of recursive call: it can open a new TCP connection,
or it can re-use the existing connection. Unfortunately, omniORB 3
only copes with the first way. Your Java ORBs are, by default, using
the second way, leading to a deadlock.

I believe some Java ORBs have an option that makes them use the first
way of creating new TCP connections. Alternatively, the omniORB 4
pre-release does not have this restriction, so it will work fine. This
is explained here:

  http://www.uk.research.att.com/cgi-bin/omni-wiki/moin.cgi/OmniOrb4DevelopmentStatus#line221


Cheers,

Duncan.

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