[omniORB] timeout associated with omniORB calls

[sheena kansal]

Hi,


How does omniORB calls like resolve() and _narrow() work in association
with timeout. i.e. how long does they try before throwing exception.

What will happen if we give timeout using SinkTimeoutMsec() API?

for example, we have code like this -
//const long SinkTimeoutMsec = 15000;
omniORB::setClientCallTimeout( rootContext,ServerReady::SinkTimeoutMsec);
o_ObjRef = rootContext->resolve(name);

what is the value of default timeout?

[Duncan Grisby]

Post by sheena kansal
What will happen if we give timeout using SinkTimeoutMsec() API?
for example, we have code like this -
//const long SinkTimeoutMsec = 15000;
omniORB::setClientCallTimeout( rootContext,ServerReady::SinkTimeoutMsec);
o_ObjRef = rootContext->resolve(name);

If the resolve() call takes more than 15 seconds, the call will result
in a CORBA::TRANSIENT exception. The minor code will be set to the value
omni::TRANSIENT_CallTimedOut.

Post by sheena kansal
what is the value of default timeout?

There is no default timeout. By default calls never time out, so they
can block forever. When opening a new TCP connection to a server, the
operating system's TCP stack will have a default connection timeout if
the server is not reachable, but that value is usually very long.

Cheers,

Duncan.

[sheena kansal]

Thanks for the quick reply.
so another question, we are hitting lot of omni::TRANSIENT_CallTimedOut
errors in a recent time.
and its happening mostly from these omniORB calls (marked with
-----------------------------------------------------------------------------------------------
try
{
omniORB::setClientCallTimeout(
rootContext,15000);
1. o_ObjRef = rootContext->resolve(name); <-------
}
catch(...){}
---------------------------------------------------------------------------------------------------
omniORB::setClientCallTimeout(
l_readyObjRef,15000);
2. if(l_readyObjRef->_non_existent())
<------------
{
cout<< " sink _non_existent true,
object not registered";
}
---------------------------------------------------------------------------------------------------
iv_Orb = CORBA::ORB_init(argc,argv);
3. o_NSObj =
iv_Orb->resolve_initial_references(NSTag.c_str()); -<-----------------
---------------------------------------------------------------------------------------------------
Do you think it will be resolved by increasing the clientCallTimeout value
from 15 sec to say 60 sec?
or its more appropriate to do a retry?
Or it could be due to some other configuration related setting?
The configuration is there in my previous mail (
http://www.omniorb-support.com/pipermail/omniorb-list/2013-June/031417.html
)

Post by sheena kansal

Post by sheena kansal
What will happen if we give timeout using SinkTimeoutMsec() API?
for example, we have code like this -
//const long SinkTimeoutMsec = 15000;
omniORB::setClientCallTimeout(

rootContext,ServerReady::SinkTimeoutMsec);

Post by sheena kansal
o_ObjRef = rootContext->resolve(name);

If the resolve() call takes more than 15 seconds, the call will result
in a CORBA::TRANSIENT exception. The minor code will be set to the value
omni::TRANSIENT_CallTimedOut.

Post by sheena kansal
what is the value of default timeout?

There is no default timeout. By default calls never time out, so they
can block forever. When opening a new TCP connection to a server, the
operating system's TCP stack will have a default connection timeout if
the server is not reachable, but that value is usually very long.
Cheers,
Duncan.
--
Duncan Grisby <duncan at grisby.org>

--
Regards,
Sheena

[Duncan Grisby]

On Mon, 2013-06-10 at 10:59 +0530, sheena kansal wrote:

[...]

so another question, we are hitting lot of
omni::TRANSIENT_CallTimedOut errors in a recent time.

[...]

omniORB::setClientCallTimeout(
l_readyObjRef,15000);
if(l_readyObjRef->_non_existent()) <------------

If a call to _non_existent is timing out after 15 seconds, something
very unusual is going on. Such a call should normally complete extremely
quickly.

Is either the client or server under very high load? Is something
messing with the system clock?

You might like to try running with these options:

-ORBtraceLevel 25 -ORBtraceInvocations 1 -ORBtraceInvocationReturns 1
-ORBtraceThreadId 1 -ORBtraceTime 1

That will output loads of debugging and may reveal where the problem is.

Duncan.