WG: [omniORB] timeout detection (client-side)

[Fischer, Clemens]

-----Ursprüngliche Nachricht-----
Von: Fischer, Clemens 
Gesendet: Mittwoch, 21. November 2007 14:01
An: 'Michael Kilburn'
Betreff: AW: [omniORB] timeout detection (client-side)

Hi,
when the server died and thus closed the connected while having outstanding requests, COMM_FAILURE must be raised. From the client's point of view the situation is the same as if the server had deliberately closed the connection.
As far is i know (but i don't know omniORB's internals very well) there is no reconnection behind the scenes in such a situation. Your server doesn't behave well, so the client should be informed about.


-----Ursprüngliche Nachricht-----
Von: Michael Kilburn [mailto:crusader.mike at gmail.com] 
Gesendet: Mittwoch, 21. November 2007 13:52
An: Fischer, Clemens
Cc: omniorb-list at omniorb-support.com
Betreff: Re: [omniORB] timeout detection (client-side)

Hi,

Hmm... From my tests I have a feeling that COMM_FAILURE gets generated
if underlying ORB had non-closed socket to the server (which died) and
and I attempt to send a request there. Which is kind of unpredictable,
since you never know if ORB has connection or not...
Question: in such cases, will omniORB (after detecting that socket
connection is dead) attempt to reestablish connection in the same call
or I need to catch these cases and call again, expecting TRANSIENT?


My original intention was to find reliably whether:
- server is 100% dead (i.e. box is reachable, but related port is not listening)
- server is potentially alive (i.e. socket can't connect due to
timeout (due to network problems, or server overload))
- server is 100% alive, but has problems in business logic (i.e.
request was sent and received successfully, but request processing
timed out, e.g. due to deadlock)
- server is 100% alive, but there are problems in CORBA layer (no
resources, protocol incompatibilities and so on)

Is it possible to do that?


On Nov 20, 2007 10:21 PM, Fischer, Clemens
<clemens.fischer at atlas-elektronik.com> wrote:
> Hi,
>
> COMM_FAILURE is raised when the server closes a connection while there are outstanding requests. This usually happens when the server crashes during execution of an interface method. When there are no outstanding requests, the server may close the connection at any time to protect itself agains too many open sockets. On the next request the client simply reconnects (transparently in the client-side ORB).
>
> TRANSIENT is raised when the server can't be connected, i.e. the client's TCP/IP connect call fails. This happens when the server process isn't running or doesn't listen, or the network is degraded, etc.
>
> Since omniORB does not support TIMEOUT exceptions out of the box, you have to set up a TRANSIENT exception handler to create them as a result of a TRANSIENT exception with a special minor code. This is described in chapter 4.7 of the omniORB User's Guide.
>
>
> // TRANSIENT exception handler function
> //
> static CORBA::Boolean transient_exception_handler(
>   void*, CORBA::ULong, const CORBA::TRANSIENT& exc)
> {
>   if (exc.minor() == omni::TRANSIENT_CallTimedout)
>   {
>     // convert TRANSIENT to TIMEOUT exception
>     throw CORBA::TIMEOUT(exc.minor(), exc.completed());
>   }
>
>   return 0;
> }
>
> // set client call timeout for one object
> //
> CORBA::ULong timeout = 1000; // ms
> omniORB::setClientCallTimeout(obj, timeout);
> omniORB::installTransientExceptionHandler(
>   obj, 0, transient_exception_handler);
>
> // or set client call timeout globally
> //
> CORBA::ULong timeout = 1000; // ms
> omniORB::setClientCallTimeout(timeout);
> omniORB::installTransientExceptionHandler(
>   0, transient_exception_handler);

-- 
Sincerely yours,
Michael.