[omniORB] Remote Invocation Problem on omniORB

[Duncan Grisby]

On Monday 30 April, "Luke Deller" wrote:

> Here are the logs from using trace level 30 with the same 
> configuration (see attached).

Aha!  This is an interesting error. It's due to a misconfiguration of
the Linux server...

On the omniNames server, we see...

> omniORB: Dispatching remote call 'list' to: =
> key<0x4e616d6553657276696365>

The client calls list()...

> omniORB: Activating: root/<0>
> omniORB: Creating ref to local: root/<0>
>  target id      : IDL:omg.org/CosNaming/BindingIterator:1.0
>  most derived id: IDL:omg.org/CosNaming/BindingIterator:1.0
> omniORB: Dispatching local call 'next_n' to root/<0>

The server creates a new BindingIterator...

> ll_send: 118 bytes
> 4749 4f50 0100 0101 6a00 0000 0000 0000 GIOP....j.......
> 0300 0000 0000 0000 0000 0000 2a00 0000 ............*...
> 4944 4c3a 6f6d 672e 6f72 672f 436f 734e IDL:omg.org/CosN
> 616d 696e 672f 4269 6e64 696e 6749 7465 aming/BindingIte
> 7261 746f 723a 312e 3000 0000 0100 0000 rator:1.0.......
> 0000 0000 1e00 0000 0101 0000 0a00 0000 ................
> 3132 372e 302e 302e 3100 f90a 0600 0000 127.0.0.1.......
> ff00 0000 0000                          ......

...and returns it to the client. But look at that "127.0.0.1" -- the
object reference returned to the client is for the loopback interface,
not the Linux machine's real IP address!

Now, when the client side receives the BindingIterator reference, it
tries to invoke on an object living at 127.0.0.1, i.e. on itself. Now,
coincidentally, there is actually a process sitting on the right port,
with an active object with the right key, but with a different
interface. So that object throws a BAD_OPERATION exception. I don't
really understand how there can be an object with the right key, since
the root POA is meant to ensure keys are never re-used, but that's
what seems to be happening.

Anyway, the solution is to configure the Linux server so it doesn't
think its IP address is 127.0.0.1. You probably need to fix
/etc/hosts.

Cheers,

Duncan.

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