[omniORB] Multiple IP Addresses Problem Naming Service

[Duncan Grisby]

On Wednesday 28 September, Steven King wrote:

> The CORBA services fail to start if the naming service has started
> from any previous history (i.e omninames-<hostname>.log file exists).
> The CORBA services fail when trying to resolve the NamingContext with
> (calls throw giopStream::CommFailure from
> giopStream.cc:1076(1,NO,TRANSIENT_ConnectFailed ) thrown from the
> omniOrb core. This appears to be the case because its switched the
> rope to another address 192.168.6.12 (which is invalid in the virtual
> server - hence the connection problem).  We can see why this may be a
> fallback address, but we don't want it to be one and cannot work out
> how to configure omniOrb/omni name to remove it.
> 
> We have set the endPoint = giop:tcp:192.168.6.14: in
> /etc/omniORB4.cfg.  This makes the naming service bind to the correct
> address and port (192.168.6.14:2809).  as well as the clients

The configuration isn't working the way you think it is. It works fine
for your own servers, since they listen on an arbitrary port on the .14
address.

However, omniNames subverts what you are trying to do by configuring its
own endPoint. It adds a command line option to itself of -ORBendPoint
giop:tcp::2809, to pin down the port to use. This means that omniNames
is listening on two endpoints, and publishing both in its IORs.

The two endpoints you have are giop:tcp:192.168.6.14:, which listens on
that specific network interface, with an OS-chosen port number (it chose
33138).  The other is giop:tcp::2809, which listens on all network
interfaces on port 2809, but only publishes one IP address in its IORs.
It picks the first non-loopback address reported to it by the OS, which
you can see is 192.168.6.12.

So, IORs published by omniNames have two endpoints specified:
192.168.6.14:33138 and 192.168.6.12:2809. When you restart omniNames,
the OS-chosen port is different, so neither endpoint is valid. The
message about choosing a different rope is just omniORB trying the
addresses in the IOR in turn, but neither is valid.

To avoid the problem, you need to prevent omniNames from looking at the
configuration file with the giop:tcp:192.168.6.14: endPoint in it (by
setting OMNIORB_CONFIG to a different file), then run omniNames with the
following options:

  omniNames -ORBendPoint giop:tcp:192.168.6.14:2809 -ignoreport

There, you are specifying precisely the endPoint you want. The
-ignoreport option is bizarrely named for some historical reason, but
what it does is prevent omniNames from adding its own endPoint option.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --