[omniORB] Client hangs while trying to narrow reference specified by corbaloc

[Patrick Hartling]

I have run into a problem when using omniINSPOA and corbaloc with
omniORB 4.0.7, and I have not been able to find any answers in the
documentation or list archives. On the server side, I provide access
to a bootstrap object through omniINSPOA, and that object returns a
reference to another object activated in a second POA (a child of
RootPOA). In case it matters, the second POA has the following
policies set: UNIQUE_ID, RETAIN, and MAIN_THREAD_MODEL, and it has
BIDIRECTIONAL_POLICY_TYPE set to BiDirPolicy::BOTH.

Everything works very well if I have the client and server running on
the same machine. If I run on two separate machines, however, the
client hangs while trying to narrow the reference to the bootstrap
object that it gets back from CORBA::ORB::string_to_object(). It
reports the following error:

omniORB: Client attempt to connect to giop:tcp:192.168.1.199:42000
omniORB: AsyncInvoker: thread id = 1 has started. Total threads = 2
omniORB: giopRendezvouser task execute for giop:tcp:192.168.1.183:37128
omniORB: AsyncInvoker: thread id = 2 has started. Total threads = 2
omniORB: Scavenger task execute.
omniORB: Client opened connection to giop:tcp:192.168.1.199:42000
omniORB: sendChunk: to giop:tcp:192.168.1.199:42000 98 bytes
omniORB: inputMessage: from giop:tcp:192.168.1.199:42000 12 bytes
omniORB: throw giopStream::CommFailure from
giopImpl10.cc:298(1,NO,COMM_FAILURE_WaitingForReply)

The server reports a communication failure while trying to un-marshal arguments:

omniORB: Server accepted connection from giop:tcp:192.168.1.183:37129
omniORB: AsyncInvoker: thread id = 5 has started. Total threads = 3
omniORB: Scavenger task execute.
omniORB: AsyncInvoker: thread id = 6 has started. Total threads = 3
omniORB: giopWorker task execute.
omniORB: Accepted connection from giop:tcp:192.168.1.183:37129 because
of this rule: "* bidir,tcp"
omniORB: inputMessage: from giop:tcp:192.168.1.183:37129 98 bytes
omniORB: sendCloseConnection: to giop:tcp:192.168.1.183:37129 12 bytes
omniORB: throw giopStream::CommFailure from
giopStream.cc:880(0,NO,COMM_FAILURE_UnMarshalArguments)

Does anyone know what would cause the different behavior when using
separate machines? I have only started using omniINSPOA today, and my
code worked fine before when using a rudimentary protocol based on the
stringified IOR. There should not be any firewall interference in this
case. I do have the bidirectional policy in place to deal with the
case of a firewall, but no requests are currently being made to use
bidirectional GIOP. I have tested various combinations of Red Hat
Enterprise Linux 4 (x86_64), Windows XP, and Mac OS X 10.4, and the
problem is the same every time.

 -Patrick


-- 
Patrick L. Hartling
http://www.137.org/patrick/