[omniORB] Curious omniNames Behavior

[Steven W. Brenneis]

Ken Feuerman wrote:
> 
> Has anyone seen the following:
> 
> When I start omniNames a first time, with
> 
> omniNames -start 8047
> 
> I get some root context IOR printed out to the console.  Then, I start
> omniNames again later, without the -start option, and I get a *different*
> IOR printed out.  This, in spite of the fact that the OMNINAMES_LOGDIR
> environment variable has not changed.
> 
> The difference between the two IOR's (as revealed by catior) is in the IP
> address.  In the -start case, the IP address is something reasonable (e.g.,
> 128.101.nnn.nnn), but in the subsequent case, the IP address is 127.0.0.1
> (canonical localhost).  The object key's are *identical*.
> 
> This is on an NT4.0 Workstation machine, running omniORB 2.6.0.  Here's a
> possible clue:  It's a DHCP client machine that does NOT have its own fixed
> IP address.
> 
> When this situation happens, it appears that clients on the same machine
> can still get in touch with the NameService, but clients on other machines
> cannot.  Any ideas what's happening?  Is DHCP getting in the way?
> 
> Thanks!
> 
> --Ken Feuerman.

After running omninames with the -start option, you must record the IOR
with the "IOR:" prefix and enter it in your registry under the key
HKEY_LOCAL_MACHINE/Software/ORL/omniORB/2.0 as a string value named
NAMESERVICE.  The OMNINAMES_LOGDIR environment variable simply specifies
where the logfile will be kept.  You got an IOR for localhost the second
time because this registry key was missing.  
DHCP can be a problem if the machine you are running omninames on loses
its lease on the IP address.  If this happens, you will have to run
omninames with the -start option again and re-record the IOR in the
registry.  Maybe you can run omninames on the domain controller or
another server with a fixed IP address?

Good luck.
Steve Brenneis