[omniORB] Re: Operating within a vserver

[Russell Kliese]

I managed to sort the problem out (or at least get things working).

The problem seemed to be related to omninames using old information when 
it was being restarted with a different endpoint option.

For example, if omninames was started with no endPoint option, it would 
start and bind to 192.168.6.14 (according to netstat), but it would pass 
192.168.6.12 to the CORBA servers, perhaps because 192.168.6.12 was the 
first available non 127.0.0.1 interface. I suspect this is related to 
some of the fancy footwork that the vserver kernel patches do.

Anyway, changing the endPoint option to giop:tcp:192.168.6.14: and 
restarting omninames doesn't change the situation until omninames' log 
file (and it's backup?) is deleted and omninames restarted. When it is 
restarted, it creates a fresh log file and everything seems to work happily.

So the trick I was missing was removing the omninames log/state file. It 
seems that the greatest pains are always caused by small things ;)

Russell

Russell Kliese wrote:

> Thank you for your suggestion, Wernke.
>
> I have tried setting the endPoint option to "endPoint = 
> giop:tcp:192.168.6.14:". This causes the following additional lines in 
> netstat:
>
> tcp        0      0 192.168.6.14:32852      192.168.6.14:32849      
> TIME_WAIT
> tcp        0      0 127.0.0.1:32850         192.168.6.14:2809       
> TIME_WAIT
>
> But the server still fails to start. Apparently the corba server is 
> attempting to connect from the localhost interface to the omniNames, 
> however, this won't work in a vserver because the localhost interface 
> is not able to be used.
>
> From my understanding, the endPoint options are used to set up the 
> addresses that the CORBA server will listen on, however, I think the 
> problem is with the CORBA server trying to contact omniNames.
>
> Is it possible to choose a different address to 127.0.0.1 that the 
> CORBA server will bind to when contacting omniNames?
>
> Russell
>
>> Hi,
>>
>> you should use the endPoint option for your server. See chapter 8.6 
>> of the
>> manual for details.
>>
>> Wernke
>>  
>>
>>> I am having a problem running an omniORB4 corba server from within a 
>>> vserver.
>>>
>>> The IP address assigned to the current vserver is 192.168.6.14, 
>>> while the host machine ip addresses are 192.168.6.12 and 127.0.0.1.
>>>
>>> omninames looks to be running correctly (netstat -an has it showing 
>>> as follows:)
>>>
>>> tcp        0      0 192.168.6.14:2809       0.0.0.0:*               
>>> LISTEN   
>>> I have set OMNIORB_USEHOSTNAME=192.168.6.14
>>> When I try to run a corba server, I get the following exception 
>>> being thrown:
>>> throw giopStream::CommFailure from 
>>> giopStream.cc:1076(0,NO,TRANSIENT_ConnectFailed)
>>>
>>> And netstat has the following additional lines:
>>>
>>> tcp        0      0 192.168.6.14:32822      192.168.6.14:32819      
>>> TIME_WAIT
>>> tcp        0      0 127.0.0.1:32820         192.168.6.14:2809       
>>> TIME_WAIT
>>>
>>> So it looks like the corba server is binding to 127.0.0.1. I suspect 
>>> this is the problem because the 127.0.0.1 address is not available 
>>> to the vservers. Is there any way to get a corba server to bind to a 
>>> different address?
>>>
>>> Thanks,
>>>
>>> Russell
>>>   
>>

-- 

<http://www.eminence.com.au/> Eminence Technology Pty Ltd
PO Box 118, Moorooka QLD 4105
Web: www.eminence.com.au <http://www.eminence.com.au/>
Ph: +61-7-3277-4100
Fax: +61-7-3105-7484