Re: Extended comm loss and TCP/IP

[SpamSpamSpam <spam@spam.com>]

Hi Mark,

Your problem is CORBA specific, though if ORBExpress raised a COMMS_FAILURE
exception within the client this would help! Theres a book "CORBA Design
Patterns" that
you might consider.  Its on my list..........

For an Ada view :)...

You could make ALL the calls "oneway" and then enter a guarded "select"
which accepts
a callback with the specified delay period or assumes a comms failure, but
this requires alot
of extra work for an exceptional condition the ORB should detect and report.

It would be better if ORBExpress on the client side "polled" the server
while awaiting responses,
raising the COMMS_FAILURE  exception if the ORB server side failed to
respond. After all this
is all meant to be invisible to you (including the TCP/IP networking).
Alternative - Wrap your calls
in tasks, assume comms failure and surprise yourself with a completion
exception !

-------------------------------------------------------------------------------------------

 with CorbaCallXWrap ;
procedure Client is
begin

    -- blar, blar , blar .....
    declare
       CorbaCall : CorbaCallXWrap.Object ; -- kick off call
       RoughTimeout : constant Duration := 600 ;
    begin
       Delay ( RoughTimeout ) ;
       -- Comms fail code here
       -- raise COMMS_FAILURE for example
    exception
       when CorbaCallXWrap.Finished => null ;
    end ;
    -- blar, blar , blar
end Client ;
---------------------------------------------------------------------------------

package CorbaCallXWrap is

    task type Object ;
    Finished : exception ;

end CorbaCallXWrap ;

-----------------------------------------------------------------------------------

package body CorbaCallXWrap is

    -- Dummy real would with in
    procedure CorbaCall is begin null ; end ;

    task body Object is
       Finished : exception ;
    begin
          CorbaCall ;
          raise Finished ;
    end Object ;

end CorbaCallXWrap ;

Cheers Glen