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

[Fischer, Clemens]

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);


-------
Clemens




-----Ursprüngliche Nachricht-----
Von: omniorb-list-bounces at omniorb-support.com [mailto:omniorb-list-bounces at omniorb-support.com] Im Auftrag von Michael Kilburn
Gesendet: Dienstag, 20. November 2007 11:42
An: omniorb-list at omniorb-support.com
Betreff: [omniORB] timeout detection (client-side)

Hi,

Is it possible to reliably distinguish these three conditions? :
- server can't be contacted (i.e. it dropped out of network and it
can't detect that, extremely overloaded, deadlocked, whatever) with
timeout set by corresponding function
- server process is dead (i.e. box is alive, but related port is
closed, box is switched off and network could detect that...)
- other conditions, such as errors in client's ORB, errors in server's
ORB (e.g. out of memory, system errors)

Currently I am totally confused by how omniORB behaves (in some cases
generates COMM_FAILURE, in some -- TRANSIENT)...

Also, what about providing nice extension -- automatically catch
std::exception in request dispatcher and generate some CORBA system
exception (passing exception::what() to the client). Right now, I have
to go through tedious process of adding this support for almost every
function in idl by catching and converting std::exception to my own
InternalError.

-- 
Sincerely yours,
Michael.

_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list