[omniORB] Squirrelly behavior from name service

[Lyle Johnson]

All,

I'm seeing some really odd behavior when attempting to connect to a name 
service running on a remote machine. Both machines are running Red Hat 
Linux 7.2; both are using omniORB-3.0.5.

If I run the name service on machine "A" and then try to access it from 
clients on the same machine, there's no problem. The "nameclt" utility 
reports the correct information about objects that have been published 
to the name service, and other client applications seem to do the right 
thing.

If I then run the name service on machine "B", modify my omniORB.cfg 
file accordingly, and then test various clients running on machine "A", 
things go wrong. But they go wrong in interesting ways ;)

For example, if I try to do a simple "list", I get the helpful error 
message:

    $ nameclt list
    list: Unexpected error encountered

But if I press on and try to "resolve" for a name that I *know* has been 
published to the remote name service, it does return an IOR string:

    $ nameclt resolve CFDRC
    IOR:...

I'm seeing similar-ish behavior in my compiled C++ client application. 
For that application, the first call to CosNaming::NamingContext::list() 
returns reasonable results, which is better than I did with the 
command-line "nameclt" tool. So it seems to establish some kind of 
connection with the remote name service. But when I later try to list 
one of the nested naming contexts, I get inconsistent results; sometimes 
it claims that that nested context has no bindings (which I know is not 
true), other times it throws exceptions.

Anyways, I have reached the eyes-glazed-over point that means even an 
obvious bug isn't going to be so obvious anymore. Can anyone suggest 
some fundamental things that I might be doing wrong, based on the 
evidence described above? I'll be glad to provide additional information 
if it would help (not sure what's useful).

Thanks in advance,

Lyle