[omniORB] Choosing specific end-points

Vladislav Vrtunski vladislav.vrtunski at dmsgroup.co.yu
Tue Apr 5 13:25:44 BST 2005


Thanks for the answers Wernke.

Our problem is not the same as yours, so I will try to explain what 
exactly is bothering us.


System description:
Each computer in our network (both clients and servers) has two LAN 
cards (100Mbps Ethernet) plugged into network A and B. Each network has 
a switch that two redundant servers and many clients are connected to.


Problem environment:
Clients obtain two references (each with two end-points) to each server. 
When a network failure appears, omniORB tries to reconnect the client to 
the active server over another end-point i.e. through the other network. 
If it fails as well, client detects that situation and activates another 
reference to the second server. The second server is now the active one. 
This mechanism seems to be very efficient, but not in all circumstances.


The Problem:
When the client initiates a remote call using reference to the active 
server, and then the cable between active server and switch is 
unplugged, the client call blocks for about 10 sec and then throws an 
exception. If we make the ORB redo the call by using exception handlers, 
the call will be successful since the ORB will now establish connection 
using the other endpoint and the same server will remain active. That is 
all great, except these 10 sec, since it is too long for our client. We 
have performed other tests of the same kind in which the server has been 
turned off, restarted, etc., and in all these tests the timeout is 
acceptable. We suspect that this timeout is related to tcp protocol 
adapter, but we would like to examine other possibilities.

Our system is to be real-time like, timeouts in communication must not 
be greater then 1-2 seconds. This requirements we cannot achieve when 
above described network failure appears (unplugging the server's network 
cable).

We thought we could overcome the problem by handling the end-points, and 
implementing our own network failure detection mechanism. Our idea was 
to switch endpoints when we detect (hopefully faster than omniORB does) 
that active network has failed.

Any thoughts?

Regards,

-- 
Vladislav Vrtunski
DMS Group
Serbia & Montenegro





More information about the omniORB-list mailing list