[omniORB] Distributed deadlock with mixed client/server apps

[Patrick Hartling]

I am having a very, very frustrating problem with omniORB 3.0.4.  My 
software system has two parts: a C++ side using omniORB, and a Java side 
using a Java ORB.  A subject/observer pattern is being used so that the 
Java side (observer) may view data held by the C++ side (subject).  As 
part of the pattern, the subject must inform its registered observers 
when it changes.  In a test program, the Java side is using a JSlider to 
visualize a single integer value contained in a C++ servant.  When the 
slider is moved, I tell the subject that the value has changed; the 
subject updates and notifies the observers.  This results in a call back 
to the Java side since the observers are Java servants.

I have attempted to recreate the sequence below:

                  Java                              C++
                  ====                              ====
      ObserverImpl    Observer           SubjectImpl    Subject
          |              |                    |            |
          |----------------------------------------------->| setValue()
          |              |          setValue()|<-----------|
          |              |                   /|            |
          |              |          notify()| |            |
          |              |                  ->|            |
          |              |                    |            |
          |      update()|<-------------------|            |
  update()|<-------------|                    |            |
          |              |                    |            |
          |----------------------------------------------->|getValue()
          |              |          getValue()|<-----------|

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.

Both Java and C++ are using POA, and the Java side should be restricted 
to IIOP 1.0 based on the CORBA URIs I have used.  I have scoured the 
omniORB mailing lists and the User Guide in hopes of finding someone with 
a similar problem.  I saw some mail traffic in May 2001 
(http://www.uk.research.att.com/omniORB/archives/2001-05/0021.html) with 
a nearly identical problem, but when I have tried it, specifying 
-ORBverifyObjectExistsAndType 0 on the command line does not fix my problem.

All hope has not been lost, however.  Based on other findings, I have 
tried making the Observer's update() method a oneway function.  This 
solves the problem, but I don't understand why I have to use a oneway 
function to fix the deadlock.  My reading of omniORB's concurrency model 
leads me to believe that it should handle this case properly, but it does 
not seem to.  Have I forgotten to do something?

  -Patrick


-- 
Patrick L. Hartling                     | Research Assistant, VRAC
patrick@vrac.iastate.edu                | 2624 Howe Hall -- (515)294-4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/