From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,FREEMAIL_FROM, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,97d2772750ae15ad X-Google-Attributes: gid103376,public From: Corey Ashford Subject: Re: Extended comm loss and TCP/IP Date: 1999/04/15 Message-ID: <37157929.C154C53F@rocketmail.com>#1/1 X-Deja-AN: 466605163 Content-Transfer-Encoding: 7bit References: <37142321.E3B0C8BE@pacbell.net> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: Rational Software Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-04-15T00:00:00+00:00 List-Id: Mark McKercher wrote: [snip] > If comm is lost while in the middle of a CORBA request and it takes 10 > or more minutes to re-establish comm, then there is trouble. It appears > as though the server side completes the request but abandons the return > to the client after 10 minutes. The client, on the otherhand, is > waiting infinitely for the return. Hence, the client side is locked up > and never frees up. > > Our orb vendor has looked at the problem and has determined that it is a > TCP/IP problem... it never sends any indication to orb of a problem. > > Has anyone else experienced such problems with TCP/IP and are there any > workarounds for such a problem? It seems like the server side ought to close the socket if it believes there's an unrecoverable error and has given up waiting for a response. That way when the client finally establishes contact again, it will be made aware by TCP/IP that the socket has closed. At this point the client ought to be able to reestablish a new connection. If the socket is just left open, and the server has given up on the protocol, it's a problem waiting to happen. Another possible solution would be to change the server so that it just never times out. - Corey