[omniORB] Immediate rope switch

[Lazar Stricevic]

Hi Duncan,

Thank you for your answer.
This small change significantly reduces reaction time to e.g. 
communication line break, which is very important for our usage (we have 
2 sec reaction time) and that why it is the only way for us to use 
omniORB. (More details about what we are using it for are available at 
http://www.dmsgroup.co.yu/)
I believe that parameter which would make this feature configurable 
would make lives significantly easier for everyone who is using omniORB 
in a real-time environment. I certainly know that it would make my life 
easier, because then I won't have to patch every new version of omniORB 
which I have been doing from version 4.0.5. :)

Cheers,
Lazar

Duncan Grisby wrote:
> On Friday 30 November, Lazar Stricevic wrote:
>
> [...]
>   
>> Upon the loss of connection, current behavior of omniORB is to try to
>> reestablish connection over the same "rope" i.e. network interface, to
>> wait if reestablishment fails (to make sure that the connection is
>> impossible over that interface), and only then switch the connection
>> to the other "rope". This makes sense in regular non-real-time usage,
>> but unfortunately that is not the case with our system.
>> We decided that the best for our system is to switch rope when it
>> encounters problems in communication (transient exception), even if it
>> is possible to continue to use current interface. The waiting proved
>> to be too costly for us.
>> Desired behavior is achieved by changing the method
>> notifyCommFailure() of the GIOP_C object (file
>> omniORB-4.1.1/src/lib/omniORB/orbcore/GIOP_C.cc). The part which
>> decides whether to check connection again over the same interface is
>> commented out. Patch file is attached.
>>
>> Is there any other, regular way to do this (without changing the code
>> of omniORB)?
>>     
>
> I think that's a reasonable way to handle your situation. There's no way
> to do it without the kind of changes you've done inside omniORB. I'm not
> sure it's a common enough requirement to make it worth exposing as a
> configuration parameter.
>
> Anyone else interested in this?
>
> Cheers,
>
> Duncan.
>
>