[omniORB] Client gets TRANSIENT_ConnectFailed exception.

[Jochen Behrens]

Duncan Grisby wrote:

> On Monday 18 August, Jochen Behrens wrote:
>
> > Dependent on the network driver state of the first non-loopback
> > interface of my server host the client application is able to get 
> access
> > to a server application or the call returns with the
> > TRANSIENT_ConnectFailed exception. The server host is a gateway and the
> > client is only able to get access via the second network interface.
>
> [...]
> > and restart client and server application the client is not able 
> anymore
> > to get access. Each subsequent call returns with the above exception.
> > That puzzles me, because client and server are only connectable via
> > <b-net> and (in my opinion) the state of the other interface shall not
> > affect client/server behaviour.
> >
> > Do I have to initiate a location forward in the client on application
> > level? Maybe I do not understand the concept of multiple network 
> support
> > and location forwarding.
>
> What you are doing should work fine, but I think your endpoint
> specifications may be a bit wrong. The trace you posted shows that the
> server actually has three endpoint specifications, two on
> 192.168.207.251, on ports 5555 and 42948, and one on 172.16.1.29, port
> 42949. That's why there are three reports of giopStream::CommFailure
> before the TRANSIENT exception is thrown. The earlier bits of trace
> show that the server is really listening on 172.16.1.29 port 5555.
> What exactly is the endpoint specification you are giving the server?
>
The enpoint specification is:

serverApp -ORBendPoint giop:tcp:192.168.207.251: -ORBendPoint 
giop:tcp:172.16.1.29:

It seems to me, that the first non-loopback interface (which is 
192.168.207.251) is always listed prior to the endpoints I explicitly 
specify.
But, however, I'm afraid that my problem is more general. If I set 
-ORBclientCallTimeOut = 0 on client side, the client is able to get a 
connection via the second interface, but it takes a long time (may take 
some minutes).  I guess that the ORB only tries to establish a 
connection  via another network interface if the TCP layer reports a 
network failure. You may take a quick look at another posting I sent on 
08/21/2003  with subject  "Latency problems  with redundant networks".
The server is indeed listening on 172.16.1.29 port 5555. because the 
client has access to the server via a corbaloc - constructed initial 
reference (the client tries all network interfaces unless it gets a 
connection). The problem appears if I try to perform requests on object 
references that are provided by this initial reference.

Thanks.

Best regards,
Jochen

> Cheers,
>
> Duncan.
>
> -- 
>  -- Duncan Grisby         --
>   -- duncan at grisby.org     --
>    -- http://www.grisby.org --
> - - - - - - - DISCLAIMER - - - - - - - -
> Unless indicated otherwise, the information contained in this message 
> is privileged and confidential, and is intended only for the use of 
> the addressee(s) named above and others who have been specifically 
> authorized to receive it. If you are not the intended recipient, you 
> are hereby notified that any dissemination, distribution or copying of 
> this message and/or attachments is strictly prohibited. The company 
> accepts no liability for any damage caused by any virus transmitted by 
> this email. Furthermore, the company does not warrant a proper and 
> complete transmission of this information, nor does it accept 
> liability for any delays. If you have received this message in error, 
> please contact the sender and delete the message. Thank you.
>


-- 
-----------------------------------
Jochen Behrens
Software Engineer

Barco Orthogon AG
Hastedter Osterdeich 222
28207 Bremen

Tel +49-421-20122-447
Fax +49-421-20122-999
www.barco-orthogon.com
Jochen.Behrens at barco.com