[tao-users] How to set the NS multicast discovery timeout

[tao-users] How to set the NS multicast discovery timeout

Post by Hans Ut » Wed, 06 Feb 2008 09:33:51


i Keith,

I don't think there is an option for that. - So you can hunt down the
timeout in the code base and recompile. But I'd suggest another route:

- Make the NS start with always the same IOR (specifying a port
with the ORBEndpoint option is all it takes).
- Use the NameServiceIOR environment variable to point to locate the NS.
(As the NS IOR does not change, you can put it in .bashrc etc.)
- Use specify the relative round trip timeout QoS for the NS-IOR,
before using it.

It's standard, will work with any ORB and will also give you an
exception, if the network hangs somewhen later.

Cheers,
Hans

Keith Nicewarner wrote:

 
 
 

[tao-users] How to set the NS multicast discovery timeout

Post by Douglas C. » Wed, 06 Feb 2008 10:37:36


Hi Keith,


I don't think so, but there's no reason that one couldn't be added. If
you folks would like to do the work and contribute this back to us that
would be great!

Thanks,

doug

 
 
 

[tao-users] How to set the NS multicast discovery timeout

Post by Steve Tott » Wed, 06 Feb 2008 12:39:16

Hi Keith,



The "service discovery timeout" is controlled by the following
macro definition in $TAO_ROOT/tao/orbconf.h:

// The default timeout receiving the location request to the TAO
// Naming, Trading and other servicesService.
#if !defined (TAO_DEFAULT_SERVICE_RESOLUTION_TIMEOUT)
#define TAO_DEFAULT_SERVICE_RESOLUTION_TIMEOUT 10
#endif /* TAO_DEFAULT_SERVICE_RESOLUTION_TIMEOUT */

So, you could #define TAO_DEFAULT_SERVICE_RESOLUTION_TIMEOUT to
your preferred value in ace/config.h file and recompile.
Obviously, that does not provide the same flexibility as a
run-time option would provide.

You can also override the value of the service resolution timeout
in code by passing it as the optional 2nd parameter to
CORBA::ORB::resolve_initial_references(). The 2nd parameter
defaults to zero (really, a null ACE_Time_Value), causing the ORB
to use the value specified by the above macro. See
$TAO_ROOT/tao/ORB.h:

/**
* This method acts as a mini-bootstrapping Naming Service,
which is
* provided by the ORB for certain well-known object
references. TAO
* supports the "NameService", "TradingService", "RootPOA",
* "ImplRepo", and "POACurrent" via this method. The @c timeout
* value bounds the amount of time the ORB blocks waiting to
* resolve the service. This is most useful for bootstrapping
* remote services, such as the "NameService" or
"TradingService",
* that are commonly resolved via multicast. By default, the
* value is 0, which means "use the @c
* TAO_DEFAULT_SERVICE_RESOLUTION_TIMEOUT timeout period".
*
* @note By using a default value for the @c timeout parameter,
* TAO will remains compliant with the CORBA
* resolve_initial_references() specification.
*/
CORBA::Object_ptr resolve_initial_references (
const char *name,
ACE_Time_Value *timeout = 0);

So, for a one-second timeout, you could just call:

CORBA::Object_var obj =
orb->resolve_initial_references(
"NameService", ACE_Time_Value(1));

You could easily turn the value into a command-line parameter to
your application (and it shouldn't be much harder to make it an
ORB initialization option).

The above call to resolve_initial_references() is, of course,
a TAO extension to the CORBA specification.

HTH,
Steve
--
----------------------------------------------------------------
Steve Totten, Principal Software Engineer and Partner
Object Computing, Inc. (OCI), St. Louis, MO, USA
http://www.yqcomputer.com/ ://www.theaceorb.com/
----------------------------------------------------------------