[omniORB] Timeout problems with omniORB 2.8.0

Mike Bendickson mike.bendickson at spanlink.com
Tue Nov 25 09:57:25 GMT 2003


I'm trying to implement reduced client-side timeouts using omniORB
2.8.0.

>From the manual:

	"Similary, how long the ORB will wait for a remote call to
complete is determined by the parameter clientCallTimeOutPeriod for the
client side and the serverCallTimeOut-Peroid for the server side. The
default values are 60 and 90 seconds for the client and the server side
respectively. These values can be changed using the command-line option
-ORBclientCallTimeOutPeriod and -ORBserverCallTimeOutPeriod. They can
also be controlled by the omniORB::callTimeOutPeriod() call."

Using callTimeoutPeriod(), I found:

1) callTimeOutPeriod() only affects calls where the client can connect
to the server.  And in those cases, clientTimeOutPeriod must have been
called on both the client and server sides.

2) callTimeOutPeriod() does NOT affect calls where the client can NOT
connect to the server.  In those cases, the IDL call was always taking
about 23 seconds.  Even with a callTimeoutPeriod() setting of 1 second.

3) When the client can connect to the server, the 1st timeout is double
the specified value.  Subsequent timeouts are the specified value.

4) scanGranularity() affects call timeouts.  I did not get this
impression from the manual, but from the header:

	
////////////////////////////////////////////////////////////////////////
	// The granularity at which the ORB scan for idle connections or
//
	// stuck remote calls can be changed by scanGranularity().
//
	// This value determines the minimum value that
//
	// idleConnectionScanPeriod() and callTimeOutPeriod() can
//
	// be relistically implemented. The default value is 5 sec.
//
	// Setting the value to zero disable scanning altogether. This
means  //
	// both scan for idle connections or stuck remote calls are
disabled  //
	// as well.
//
	//
//
	_CORBA_MODULE_FN void scanGranularity(CORBA::ULong sec);
//
	// Note: This function is *non-thread safe*!!! The behaviour of
//
	//       concurrent calls to this function is undefined.
//

5) None of these functions are thread safe.  Not a big deal, but more of
an FYI for people searching for help on omniORB timeouts as this was not
mentioned in the manual.

My question is this:  Is it possible (without orb modification) to
implement consistent client side timeouts in 2.8.0?  Consistent meaning
always timing out after the same number of seconds, regardless of the
cause of the timeout (not connected or server just slow).

If not, then is this addressed in 4.0?

Thanks,
-Mike Bendickson
 Spanlink Communications
 mike.bendickson at spanlink.com
 (763)971-2274 




More information about the omniORB-list mailing list