[tao-users] TRANSIENT instead of TIMEOUT exception

Discussion:

(too old to reply)

John Fletcher

2005-04-08 16:15:10 UTC

TAO VERSION: 1.4.4
ACE VERSION: 5.4.4

HOST MACHINE and OPERATING SYSTEM:
Windows 2000 on Pentium 4 PC

TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
COMPILER NAME AND VERSION (AND PATCHLEVEL):
Microsoft Visual C++ 6.0 with SP6

CONTENTS OF $ACE_ROOT/ace/config.h:
#define ACE_HAS_STANDARD_CPP_LIBRARY 1
#define ACE_HAS_STDCPP_STL_INCLUDES 1

#include "ace/config-Win32.h"

CONTENTS OF $ACE_ROOT/include/makeinclude/platform_macros.GNU
(unless
this isn't used in this case, e.g., with Microsoft Visual C++):

CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
(used by MPC when you generate your own makefiles):

AREA/CLASS/EXAMPLE AFFECTED:
Relative Roundtrip Timeout

DOES THE PROBLEM AFFECT:
COMPILATION?
LINKING?
EXECUTION?
Yes
OTHER (please specify)?

SYNOPSIS:
Timeout during connect phase of a remote invocation throws a TRANSIENT
rather than a TIMEOUT exception.

DESCRIPTION:
Use Messaging::RELATIVE_RT_TIMEOUT_POLICY_TYPE to set a roundtrip
timeout.
Then attempt an operation on an object reference, the remote
server for which is disconnected from the network (tcp/ip).

After the timeout expires, an exception is thrown. So far so good.
But the exception is not CORBA::TIMEOUT as it used to be in earlier
versions of TAO but is CORBA::TRANSIENT.

If the timeout is in the request rather than the connect phase, the
exception is CORBA::TIMEOUT as expected.

REPEAT BY:

SAMPLE FIX/WORKAROUND:

Regards,
John Fletcher

Balachandran Natarajan

2005-04-10 05:12:18 UTC

Permalink

John-

Post by John Fletcher
TAO VERSION: 1.4.4
ACE VERSION: 5.4.4
Windows 2000 on Pentium 4 PC
Microsoft Visual C++ 6.0 with SP6
#define ACE_HAS_STANDARD_CPP_LIBRARY 1
#define ACE_HAS_STDCPP_STL_INCLUDES 1
#include "ace/config-Win32.h"
CONTENTS OF $ACE_ROOT/include/makeinclude/platform_macros.GNU
(unless
CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
Relative Roundtrip Timeout
COMPILATION?
LINKING?
EXECUTION?
Yes
OTHER (please specify)?
Timeout during connect phase of a remote invocation throws a TRANSIENT
rather than a TIMEOUT exception.
Use Messaging::RELATIVE_RT_TIMEOUT_POLICY_TYPE to set a roundtrip
timeout.
Then attempt an operation on an object reference, the remote
server for which is disconnected from the network (tcp/ip).
After the timeout expires, an exception is thrown. So far so good.
But the exception is not CORBA::TIMEOUT as it used to be in earlier
versions of TAO but is CORBA::TRANSIENT.

Hmm.. I was about to tell you that TCP timeout had fired before your
timeout. Since you say it worked with earlier versions of TAO, would it
be possible for you to provide a simple test that reproduces this problem?

Thanks
bala

Post by John Fletcher
If the timeout is in the request rather than the connect phase, the
exception is CORBA::TIMEOUT as expected.
Regards,
John Fletcher

Milan Cvetkovic

2005-04-12 01:24:46 UTC

Permalink

I reported a related, if not same problem with TAO-5.4.1, on Linux and
Solaris.

Please see thread:

http://groups-beta.google.com/group/comp.soft-sys.ace/browse_thread/thread/1fa1585416a93907/7bba5d04321c9fdf#7bba5d04321c9fdf

I have not had a chance to try this on 5.4.4 yet, but I suspect it is
the same issue.

Milan.

Post by Balachandran Natarajan
John-

Post by John Fletcher
If the timeout is in the request rather than the connect phase, the
exception is CORBA::TIMEOUT as expected.
Regards,
John Fletcher

John Fletcher

2005-04-11 18:27:59 UTC

Permalink

Post by Balachandran Natarajan

Post by John Fletcher
Use Messaging::RELATIVE_RT_TIMEOUT_POLICY_TYPE to set a roundtrip
timeout.
Then attempt an operation on an object reference, the remote
server for which is disconnected from the network (tcp/ip).
After the timeout expires, an exception is thrown. So far so good.
But the exception is not CORBA::TIMEOUT as it used to be in earlier
versions of TAO but is CORBA::TRANSIENT.

OK, I take it back. The behaviour was the same in earlier versions of TAO.
However, I am still curious as to whether this is the "correct" behaviour.
The program certainly seems to wait for the Round-Trip timeout period before
throwing the TRANSIENT exception.

Example program below.

John

__
// timeout test

#include "ace/version.h"
#include "ace/Log_Msg.h"

#include "tao/corba.h"
#include "tao/TimeBaseC.h"
#include "tao/Messaging/Messaging.h"

#include "orbsvcs/orbsvcs/CosNamingC.h"

int main(int argc, char * argv[])
{
ACE_DEBUG(( LM_INFO, "Using ACE version %C\n", ACE_VERSION ));

// Initialise ORB
CORBA::ORB_var Orb = CORBA::ORB_init(argc, argv);

// Set round-trip timeout
const int timeout_secs = 5;

CORBA::Object_var obj = Orb->resolve_initial_references("ORBPolicyManager");
CORBA::PolicyManager_var policy_manager = CORBA::PolicyManager::_narrow(obj.in());

CORBA::PolicyList policy_list;
policy_list.length(0);
policy_manager->set_policy_overrides(policy_list, CORBA::SET_OVERRIDE);

TimeBase::TimeT timeout = timeout_secs * 10000000;
CORBA::Any orb_timeout;
orb_timeout <<= timeout;
policy_list.length(1);
policy_list[0] = Orb->create_policy(
Messaging::RELATIVE_RT_TIMEOUT_POLICY_TYPE, orb_timeout);

policy_manager->set_policy_overrides(policy_list, CORBA::SET_OVERRIDE);

// Now try to contact a server.
// Use a remote machine that is unreachable on the network.
const char * obj_ref = "corbaloc:iiop:***@123.123.123.123:4567/NameService";

obj = Orb->string_to_object(obj_ref);

CosNaming::NamingContext_var inc;
if(!CORBA::is_nil(obj))
{
ACE_DEBUG(( LM_INFO, "Attempting to contact %C\n", obj_ref ));
try
{
inc = CosNaming::NamingContext::_narrow(obj.in());
ACE_DEBUG(( LM_INFO, "OK\n" ));
}
catch(CORBA::Exception & e)
{
ACE_DEBUG(( LM_INFO, "Exception: %C\n", e._name() ));
}
}

return 0;
}

Douglas C. Schmidt

2005-04-11 23:50:38 UTC

Permalink

Hi John,

Post by John Fletcher
OK, I take it back. The behaviour was the same in earlier versions
of TAO. However, I am still curious as to whether this is the
"correct" behaviour.

Here's my $0.02 on this:

. If the connection can't be established a "TRANSIENT" exception
indicates to the client that there's something amiss with the
network connection or the host.

. If an operation times out that may indicate that the host is
overloaded, which is different than a connection failure, hence the
different exception (i.e., "TIMEOUT").

Of course, Bala may have a different set of reasons here, but I can
imagine wanting to distinguish the two failure cases by having two
different exceptions. Bala, what's your take on this?

Take care,

Doug

Post by John Fletcher
Example program below.
John
__
// timeout test
#include "ace/version.h"
#include "ace/Log_Msg.h"
#include "tao/corba.h"
#include "tao/TimeBaseC.h"
#include "tao/Messaging/Messaging.h"
#include "orbsvcs/orbsvcs/CosNamingC.h"
int main(int argc, char * argv[])
{
ACE_DEBUG(( LM_INFO, "Using ACE version %C\n", ACE_VERSION ));
// Initialise ORB
CORBA::ORB_var Orb = CORBA::ORB_init(argc, argv);
// Set round-trip timeout
const int timeout_secs = 5;
CORBA::Object_var obj = Orb->resolve_initial_references("ORBPolicyManager");
CORBA::PolicyManager_var policy_manager = CORBA::PolicyManager::_narrow(obj.in());
CORBA::PolicyList policy_list;
policy_list.length(0);
policy_manager->set_policy_overrides(policy_list, CORBA::SET_OVERRIDE);
TimeBase::TimeT timeout = timeout_secs * 10000000;
CORBA::Any orb_timeout;
orb_timeout <<= timeout;
policy_list.length(1);
policy_list[0] = Orb->create_policy(
Messaging::RELATIVE_RT_TIMEOUT_POLICY_TYPE, orb_timeout);
policy_manager->set_policy_overrides(policy_list, CORBA::SET_OVERRIDE);
// Now try to contact a server.
// Use a remote machine that is unreachable on the network.
obj = Orb->string_to_object(obj_ref);
CosNaming::NamingContext_var inc;
if(!CORBA::is_nil(obj))
{
ACE_DEBUG(( LM_INFO, "Attempting to contact %C\n", obj_ref ));
try
{
inc = CosNaming::NamingContext::_narrow(obj.in());
ACE_DEBUG(( LM_INFO, "OK\n" ));
}
catch(CORBA::Exception & e)
{
ACE_DEBUG(( LM_INFO, "Exception: %C\n", e._name() ));
}
}
return 0;
}

--
Dr. Douglas C. Schmidt Professor and Associate Chair
Electrical Engineering and Computer Science TEL: (615) 343-8197
Institute for Software Integrated Systems WEB: www.dre.vanderbilt.edu/~schmidt
Vanderbilt University, Nashville TN, 37203 NET: ***@vanderbilt.edu

Balachandran Natarajan

2005-04-12 08:16:21 UTC

Permalink

Milan-

What you reported was fixed. Please see

Fri Jun 25 06:12:49 2004 Balachandran Natarajan <***@dre.vanderbilt.edu>

* tao/Invocation_Adapter.cpp (TAO):

Removed wrong comments in the file.

* tao/IIOP_Connector.cpp (make_connection):
* tao/Strategies/SCIOP_Connector.cpp:
* tao/Strategies/UIOP_Connector.cpp:

......
knows whether it was timeout on the handler or a timeout to
drive the reactor. This never set the errno which we in TAO
check to see whether it was timeout. This lead to a problem
where timeouts where being seen as transient exceptions. Thanks
to Milan Cvetkvic <milan dot cvetkovic at mpathix dot com> for
reporting this problem.

I think you are talking about this and this was addressed. Looks like
John may have a slightly different problem. HTH

Thanks
Bala

Post by Milan Cvetkovic
I reported a related, if not same problem with TAO-5.4.1, on Linux and
Solaris.
http://groups-beta.google.com/group/comp.soft-sys.ace/browse_thread/thread/1fa1585416a93907/7bba5d04321c9fdf#7bba5d04321c9fdf
I have not had a chance to try this on 5.4.4 yet, but I suspect it is
the same issue.
Milan.

Post by Balachandran Natarajan
John-

Post by John Fletcher
If the timeout is in the request rather than the connect phase, the
exception is CORBA::TIMEOUT as expected.
Regards,
John Fletcher

Milan Cvetkovic

2005-04-12 17:14:06 UTC

Permalink

Post by Balachandran Natarajan
Milan-
What you reported was fixed. Please see

Great, thanks!

Milan.

Post by Balachandran Natarajan
Removed wrong comments in the file.
......
knows whether it was timeout on the handler or a timeout to
drive the reactor. This never set the errno which we in TAO
check to see whether it was timeout. This lead to a problem
where timeouts where being seen as transient exceptions. Thanks
to Milan Cvetkvic <milan dot cvetkovic at mpathix dot com> for
reporting this problem.
I think you are talking about this and this was addressed. Looks like
John may have a slightly different problem. HTH
Thanks
Bala

Post by Balachandran Natarajan
John-

Post by John Fletcher
If the timeout is in the request rather than the connect phase, the
exception is CORBA::TIMEOUT as expected.
Regards,
John Fletcher

John Fletcher

2005-04-12 13:27:54 UTC

Permalink

I can see there could be different points of view on this.
My perspective is:

I am making a series of requests on a server. If the server is
disconected from the network before the first request, I get a
TRANSIENT exception after the timeout has expired. However, if
the server is disconnected after the first request, I get a
TIMEOUT exception on the next request. In both cases the problem
is the same so I'd like to get the same exception.

The exception has been thrown because the timeout expired and I
would like to know in my code that I spent the timeout period,
e.g. 5 secs, on the request attempt. If, for example the host is
reachable but there is no servant running, I get a TRANSIENT
exception much quicker (after about 1 sec).

Regards,
John

Post by Douglas C. Schmidt
. If the connection can't be established a "TRANSIENT" exception
indicates to the client that there's something amiss with the
network connection or the host.
. If an operation times out that may indicate that the host is
overloaded, which is different than a connection failure, hence the
different exception (i.e., "TIMEOUT").
Of course, Bala may have a different set of reasons here, but I can
imagine wanting to distinguish the two failure cases by having two
different exceptions. Bala, what's your take on this?
Take care,
Doug

Johnny Willemsen

2005-04-14 19:03:53 UTC

Permalink

Hi,

What is now the conclusion on this? I think this is bug in TAO or not? Bala,
your statement in a previous e-mail was not clear to me. John, if Bala
agrees this is an issue, can you store it in bugzilla so that it doesn't get
lost.

Johnny

-----Original Message-----
Sent: dinsdag 12 april 2005 11:41
Subject: RE: [tao-users] TRANSIENT instead of TIMEOUT exception
I can see there could be different points of view on this.
I am making a series of requests on a server. If the server is
disconected from the network before the first request, I get a
TRANSIENT exception after the timeout has expired. However, if
the server is disconnected after the first request, I get a
TIMEOUT exception on the next request. In both cases the problem
is the same so I'd like to get the same exception.
The exception has been thrown because the timeout expired and I
would like to know in my code that I spent the timeout period,
e.g. 5 secs, on the request attempt. If, for example the host is
reachable but there is no servant running, I get a TRANSIENT
exception much quicker (after about 1 sec).
Regards,
John

hence the

Post by Douglas C. Schmidt
different exception (i.e., "TIMEOUT").
Of course, Bala may have a different set of reasons here, but I can
imagine wanting to distinguish the two failure cases by having two
different exceptions. Bala, what's your take on this?
Take care,
Doug

Johnny Willemsen

2005-04-14 20:31:40 UTC

Permalink

Hi,

I think this is maybe the underlying problem of the bug report 2074. I would
go the conclusion that the user should geta timeout, only when the orb
definitively has decided the other party is not reachable then you get a
transient.

Johnny

-----Original Message-----
Sent: donderdag 14 april 2005 21:10
Subject: Re: [tao-users] TRANSIENT instead of TIMEOUT exception
Hi Folks,

Post by Johnny Willemsen
What is now the conclusion on this? I think this is bug in

TAO or not?

Post by Johnny Willemsen
Bala, your statement in a previous e-mail was not clear to me. John,
if Bala agrees this is an issue, can you store it in

bugzilla so that

Post by Johnny Willemsen
it doesn't get lost.

I have no commitment to either approach, so whatever seems to
make more
sense to others is fine with me. We just need to be able to
justify/document what the behavior is.
Thanks,
Doug