Issue 3678: Interceptors must provide a retry mechanism (interceptors-rtf) Source: International Business Machines (Mr. Russell Butek, ) Nature: Uncategorized Issue Severity: Summary: This interceptor requirement comes from the work in CSIv2. Interceptors are only concerned with transport-level requests, whereas security needs to carry information around based on the user-level request which, given retries, could span multiple transport-level requests. To support this requirement, they need a retry mechanism. The interceptors already have a mechanism that could be used to implement retries - the LocateRequest exception. But is this appropriate? Should some other mechanism be create to distinguish retries on the same IOR from forwards to different IORs? If the retries are done often, then something other than exception should be used. Perhaps we could supply a retry method. This method would indicate to the ORB that successive interceptors' receive_other interception points should be called and that, once this transport-level request is complete, a new request should be initiated with the same user-level parameters. Resolution: Close issue with no change. This is no longer a CSIv2 requirement Revised Text: Actions taken: June 18, 2000: received issue April 26, 2010: closed issue Discussion: End of Annotations:===== From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA19492; Sun, 18 Jun 2000 15:43:36 -0500 Received: from d54mta02.raleigh.ibm.com (d54mta02.raleigh.ibm.com [9.67.228.34]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id PAA65262; Sun, 18 Jun 2000 15:53:28 -0400 Received: by d54mta02.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256902.006D3D92 ; Sun, 18 Jun 2000 15:53:11 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org, issues@omg.org cc: csi_submitters@concept5.com Message-ID: <85256902.006D3BCE.00@d54mta02.raleigh.ibm.com> Date: Sun, 18 Jun 2000 21:38:45 +0100 Subject: Interceptors must provide a retry mechanism Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: U"5e9p*2e9<9^d9m^Ke9 This interceptor requirement comes from the work in CSIv2. Interceptors are only concerned with transport-level requests, whereas security needs to carry information around based on the user-level request which, given retries, could span multiple transport-level requests. To support this requirement, they need a retry mechanism. The interceptors already have a mechanism that could be used to implement retries - the LocateRequest exception. But is this appropriate? Should some other mechanism be create to distinguish retries on the same IOR from forwards to different IORs? If the retries are done often, then something other than exception should be used. Perhaps we could supply a retry method. This method would indicate to the ORB that successive interceptors' receive_other interception points should be called and that, once this transport-level request is complete, a new request should be initiated with the same user-level parameters. Russell Butek butek@us.ibm.com Date: Tue, 1 Aug 2000 14:46:21 -0700 (PDT) Message-Id: <200008012146.OAA28110@shorter.eng.sun.com> From: Harold Carr To: juergen@omg.org Cc: interceptors-ftf@omg.org, csi_submitters@concept5.com Subject: issue 3677, 3678, 3679 Content-Type: text X-UIDL: CR@e9RcOd9p"O!!@b&!! Juergen, interceptors ftf will be voting on these issues soon. For some reason, the following discussion did not make it into the issue archive for these issues. I am enclosing it again. Could you please ensure that this is in the archive for issues 3677, 3678, 3679? Thanks, Harold ============================================================================== The following is a sketch of a proposal for satisfying CSIv2 requirments stated (along with use-cases) in: http://cgi.omg.org/cgi-bin/doc?orbos/2000-06-20 That document basically calls for a feedback mechanism from client side receive_* points to subsequent send_request points due to retries. Please respond by either submitting an alternate solution or elaborating/fixing this one. Cheers, Harold ------------------------- 1st change: Feedback - 3677 CSIv2 needs to carry information scoped at the client invocation level which, given retries, could span multiple transport-level requests. The existing RequestInfo::request_id is scoped with transport-level requests so it cannot meet those needs. ClientRequestInfo::invocation_id is introduced to satisfy this requirement: local interface ClientRequestInfo : RequestInfo { ... readonly attribute unsigned long invocation_id; ... }; ClientRequestInfo::invocation_id would uniquely identify the invocation regardless of the number of transport level requests used to satisfy the invocation. Security could use invocation_id to index into a cookie jar to feedback information from a client receive_* point to a subsequent send_request due to retries. ------------------------- 2nd change: Cleanup - 3679 If a security interceptor indicates that a retry should occur (and stores the appropriate data), it does not know whether that retry actually does occur. For example, a successive interceptor may raise an exception. To signal that client invocation scoped cookies should be cleaned up a new interceptor type with associated points is introduced: local interface ClientInvocationInterceptor : Interceptor { void invocation_begin (in ClientRequestInfo ri); void invocation_end (in ClientRequestInfo ri); }; invocation_begin would be invoked before the 1st send_request (or send_poll) which services the client invocation. It would not be invoked on subsequent send_* points due to retries. invocation_end would be invoked after the last receive_* which services the client invocation, before returning control to the client. These points are not allowed to raise exceptions. If they do raise System Exceptions, the ORB must ignore them. ------------------------- 3rd change: retries - 3678 An interceptor may want to force a retry. Currently this can be done by raising ForwardRequest. However, if the forwarded object is identical to the initial target, this may result in a different profile being selected, which may not be the desired semantics. To tell the ORB to retry using the same IOR and same profile within that IOR a new exception is introduced: exception Retry { }; local interface ClientRequestInterceptor : Interceptor { void send_request (in ClientRequestInfo ri) raises (ForwardRequest, Retry); void send_poll (in ClientRequestInfo ri); void receive_reply (in ClientRequestInfo ri); void receive_exception (in ClientRequestInfo ri); raises (ForwardRequest, Retry); void receive_other (in ClientRequestInfo ri); raises (ForwardRequest, Retry); }; ------------------------- Questions: What happens if all the tagged components in the selected profile have been tried unsuccessfully? It would seem that it would be useful to be able to specify to select "the next" profile. What happens if the server raises ForwardRequest, which is reported to receive_other and then receive_other raises Retry? It seems that it should do as told - ignore the ForwardRequest from the server and retry the same IOR/profile. How do retries based on the fault tolerance specification work viz-a-viz interceptors in general and the above proposal? For example, if FT does a retry without interceptors does the retry show up as a send_request with appropriate target and effective_target attributes? What does security's retry do to the FT algorithms? Are there any other CORBA-defined retry mechanisms?