[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