Issue 2538:  TIMEOUT system exception issue (messaging-rtf)
Source:  (, )
Nature:  Clarification
Severity: 
Summary: Summary: 3) The definition of the TIMEOUT system exception says that it is 
 raised "when no delivery has been made and the specified 
 time-to-live period has been exceeded." It does not specify 
 delivery of requests or replies specifically, so presumably it 
 applies to both. It is not easy to see what it means to require 
 generation of a TIMEOUT exception for a reply that has been 
 processed but delayed on the network. What raises the exception? 
 Does a router replace the response with the exception? This seems 
 to be out of scope for router behavior. Does the ORB of the 
 client or ReplyHandler replace the response with the exception 
 before delivering it? Possibly the intent was to allow delayed 
 responses to be dropped; at least this avoids cluttering the 
 network with obsolete packets but the wording of the section does 
 not allow this. This needs to be clarified. 
 

Resolution: close, no change
Revised Text: 
Actions taken:
March 15, 1999: received issue
October 3, 2001: closed issue
Discussion: 
Not clear what is being requested. Specific sections of AMI define when 
TIMEOUT is to be raised. It does leave a lot of freedom for the implementor to decide 
when to actually raise this exception. Indeed there are significant quality of implementations 
issues involving proper design of asynchronous invocation systems. it is not clear what 
more needs to be said in a standard specifciation. 

End of Annotations:=====
X-Sender: siegel@192.67.184.65
Date: Sat, 13 Mar 1999 12:58:57 -0500
To: issues
From: Jon Siegel <siegel@omg.org>
Subject: three issues on AMI

Hi --

Here are three issues on AMI:


3) The definition of the TIMEOUT system exception says that it is 
raised "when no delivery has been made and the specified 
time-to-live period has been exceeded." It does not specify 
delivery of requests or replies specifically, so presumably it 
applies to both. It is not easy to see what it means to require 
generation of a TIMEOUT exception for a reply that has been 
processed but delayed on the network. What raises the exception? 
Does a router replace the response with the exception? This seems 
to be out of scope for router behavior. Does the ORB of the 
client or ReplyHandler replace the response with the exception 
before delivering it? Possibly the intent was to allow delayed 
responses to be dropped; at least this avoids cluttering the 
network with obsolete packets but the wording of the section does 
not allow this. This needs to be clarified. 


Date: Wed, 06 Jun 2001 18:27:56 -0400
From: Jishnu Mukerji <jishnu_mukerji@hp.com>
Reply-To: jishnu_mukerji@hp.com
Organization: Hewlett-Packard EIAL, Florham Park NJ, USA
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: orb_revision@omg.org
Subject: Proposed resolution for Issue 2538
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: YH>!!EJ9!!7)V!!jD3!!
Status: RO

The following resolution will appear in the next vote unless there are
any significant objections.

Jishnu.

_______________________________________________________________
Issue 2538: TIMEOUT system exception issue (messaging-rtf)

Nature: Clarification 
Severity: 

Summary: The definition of the TIMEOUT system exception says that it
is
raised "when no delivery has been made and the specified time-to-live
period has been exceeded." It does not specify delivery of requests or
replies specifically, so presumably it applies to both. It is not easy
to see what it means to require generation of a TIMEOUT exception for
a
reply that has been processed but delayed on the network. What raises
the exception? Does a router replace the response with the exception?
This seems to be out of scope for router behavior. Does the ORB of the
client or ReplyHandler replace the response with the exception before
delivering it? Possibly the intent was to allow delayed responses to
be
dropped; at least this avoids cluttering the network with obsolete
packets but the wording of the section does not allow this. This needs
to be clarified. 

Resolution: Not clear what is being requested. Specific sections of
AMI
define when TIMEOUT is to be raised. It does leave a lot of freedom
for
the implementor to decide when to actually raise this
exception. Indeed
there are significant quality of implementations issues involving
proper
design of asynchronous invocation systems. it is not clear what more
needs to be said in a standard specifciation. 

Revised Text: 

Actions taken: Close no change