Date: Thu, 12 Oct 2000 14:38:51 +0100 From: Eoghan Glynn X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: interceptors-ftf@omg.org Subject: Portable interceptors and invocation timeouts Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: cd$e9*OO!!o-?!!+p*!! Folks, I'd like to raise an issue and garner feedback on the interaction of the Messaging timeout QoS policies (or indeed any proprietary invocation timeout mechanism) and portable interceptors. Where a bound is being imposed on request and/or reply delivery, and portable interceptors are present in the client- and/or server-side binding, these interceptors surely must be made aware of the relevant timeout(s) so that they may bound any potentially blocking activities they engage in. Assuming that it would be unacceptable to dictate that potentially blocking activity (such as making a subsidiary invocation) may not be undertaken in interception point operations, it appears some addition to the PortableInterceptor::RequestInfo interface is required to facilitate the Messaging timeout policies at least. For instance, the absolute request and reply expiry times could be passed as additional attributes: module PortableInterceptor { interface RequestInfo { // ... readonly attribute TimeBase::UtcT request_end_time; readonly attribute TimeBase::UtcT reply_end_time; }; }; the former bounding the send_request, send_poll, receive_request_service_contexts and receive_request interception points and the latter bounding the send_reply, send_exception, send_other, receive_reply, receive_exception and receive_other interception points. Of course this all relies on the discipline of the portable interceptor implementor, i.e. that they do not ignore the constraints imposed by the timeouts. Regards, Eoghan Glynn. Orbix2000/Java Engineering Team. Date: Wed, 13 Nov 2002 13:52:16 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Question about 3947 What do people feel about adding two operations to RequestInfo for giving access to info about invocation timeouts to PIs? Of course this will need to be done in a way that does not break backward compatibility etc. The alternative is to not do it and close it no change, but that does make it hard for PIs to honor timing constraints in a portable way. Then again the framework that the PI is running within can perhaps enforce the timing requirements by aborting operations when time runs out etc. If we want to take that approach then we could close this one with an appropriate addition of text at an appropriate place mentioning that this is how timing constraints are expected to be enforced on PI. Thoughts? Comments? Jishnu. _____________________________________________________________________ Issue 3947: Portable interceptors and invocation timeouts (interceptors-rtf) Click http://cgi.omg.org/issues/issue3947.txt for this issue's archive. Source: IONA (Mr. Eoghan Glynn, eglynn@iona.com) Nature: Uncategorized Issue Severity: Summary: I'd like to raise an issue and garner feedback on the interaction of the Messaging timeout QoS policies (or indeed any proprietary invocation timeout mechanism) and portable interceptors. Where a bound is being imposed on request and/or reply delivery, and portable interceptors are present in the client- and/or server-side binding, these interceptors surely must be made aware of the relevant timeout(s) so that they may bound any potentially blocking activities they engage in. Assuming that it would be unacceptable to dictate that potentially blocking activity (such as making a subsidiary invocation) may not be undertaken in interception point operations, it appears some addition to the PortableInterceptor::RequestInfo interface is required to facilitate the Messaging timeout policies at least. Sender: jbiggar@Resonate.com Date: Wed, 13 Nov 2002 14:05:43 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: corba-rtf@omg.org Subject: Re: Question about 3947 Jishnu Mukerji wrote: > > What do people feel about adding two operations to RequestInfo for > giving access to info about invocation timeouts to PIs? Of course this > will need to be done in a way that does not break backward compatibility > etc. The alternative is to not do it and close it no change, but that > does make it hard for PIs to honor timing constraints in a portable way. > Then again the framework that the PI is running within can perhaps > enforce the timing requirements by aborting operations when time runs > out etc. If we want to take that approach then we could close this one > with an appropriate addition of text at an appropriate place mentioning > that this is how timing constraints are expected to be enforced on PI. > > Thoughts? Comments? Why can't a PI implementation just use ClientRequestInfo::get_request_policy on the client side or RequestInfo::get_request_service_context on the server side to query the timeout policy values directly if it needs to? I say close no change. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 13 Nov 2002 22:16:33 +0000 From: Harold Carr X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en To: Jonathan Biggar CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Question about 3947 > Why can't a PI implementation just use > ClientRequestInfo::get_request_policy on the client side or > RequestInfo::get_request_service_context on the server side to query > the > timeout policy values directly if it needs to? > > I say close no change. I agree. I especially do not want to see the messaging time specification apis added to PI attributes. H Date: Wed, 13 Nov 2002 17:18:21 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: corba-rtf@omg.org Subject: Re: Question about 3947 Jonathan Biggar wrote: > > Jishnu Mukerji wrote: > > > > What do people feel about adding two operations to RequestInfo for > > giving access to info about invocation timeouts to PIs? Of course this > > will need to be done in a way that does not break backward compatibility > > etc. The alternative is to not do it and close it no change, but that > > does make it hard for PIs to honor timing constraints in a portable way. > > Then again the framework that the PI is running within can perhaps > > enforce the timing requirements by aborting operations when time runs > > out etc. If we want to take that approach then we could close this one > > with an appropriate addition of text at an appropriate place mentioning > > that this is how timing constraints are expected to be enforced on PI. > > > > Thoughts? Comments? > > Why can't a PI implementation just use > ClientRequestInfo::get_request_policy on the client side or > RequestInfo::get_request_service_context on the server side to query the > timeout policy values directly if it needs to? > > I say close no change. Good, I always prefer to close things no change. Makes my job easier:-) Jishnu. Date: Wed, 13 Nov 2002 17:24:31 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Proposed resolution for 3947 The following resolution will appear in a vote in the near future unless there is serious technical objection to it. Thanks, Jishnu. _______________________________________________________________________________ Issue 3947: Portable interceptors and invocation timeouts (interceptors-rtf) Click http://cgi.omg.org/issues/issue3947.txt for this issue's archive. Source: IONA (Mr. Eoghan Glynn, eglynn@iona.com) Nature: Uncategorized Issue Severity: Summary: I'd like to raise an issue and garner feedback on the interaction of the Messaging timeout QoS policies (or indeed any proprietary invocation timeout mechanism) and portable interceptors. snip snip see archive Resolution: a PI implementation can just use ClientRequestInfo::get_request_policy on the client side or RequestInfo::get_request_service_context on the server side to query the timeout policy values directly if it needs to. Close no change Revised Text: Actions taken: Close no change Date: Tue, 26 Nov 2002 15:27:23 -0500 From: Bob Kukura User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en To: Jishnu Mukerji CC: corba-rtf@omg.org Subject: Re: CORBA Core RTF Vote 8 Announcement X-OriginalArrivalTime: 26 Nov 2002 20:29:35.0164 (UTC) FILETIME=[88B8E7C0:01C2958A] IONA votes as follows: 3609 - YES 3615 - YES 3770 - YES 3947 - NO - Determining the actual request and reply end times from the effective Policies is not trivial. Also, when relative timeouts are involved, determining the end times accurately requires knowing exactly when processing of the request began, which is not available to Portable Interceptor implementations. Our ORB provides extensions to PI that provide these end time attbitutes, and our customers find them useful.They would be more useful if they were portable. 4290 - YES 4554 - YES 5333 - NO - This whole notion of passing in a 'len' param with the DII was completely useless even with the original C mapping. There is no justification for the programmer to have to calculate a value that the ORB could calculate itself, but which the ORB generally doesn't even need. If any changes are going to be made to the definition of the 'len' param, I'd much rather see them remove any sematics from the core and instead delegate this to the language mappings. 5663 - YES 5664 - YES 5672 - YES R3 - YES - Assuming the changes are straightforward. R4 - YES - There should never be a need to copy the slot data during server side processing of a request, and the same slot data should be visible via TSC and RSC for a particular request. The data is associated with the request for the duration, and with threads during upcalls into application level code. We do not want to add any further constraints on what threads the ORB might use to make upcalls into application level code, just clarify that the same slot data that is accessible via the RSC is accessable as TSC during these upcalls. -Bob Jishnu Mukerji wrote: Folks, Vote 8 of the CORBA Core RTF is now available at: http://cgi.omg.org/pub/orbrev/votes/corba_rtf_vote_8.html It is due on November 26, so you have a week to vote on it. Please do vote early and vote often. As usual if you do vote often, only the last vote cast by you will count. Thanks, Jishnu. Date: Tue, 26 Nov 2002 15:27:23 -0500 From: Bob Kukura User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en To: Jishnu Mukerji CC: corba-rtf@omg.org Subject: Re: CORBA Core RTF Vote 8 Announcement X-OriginalArrivalTime: 26 Nov 2002 20:29:35.0164 (UTC) FILETIME=[88B8E7C0:01C2958A] IONA votes as follows: 3609 - YES 3615 - YES 3770 - YES 3947 - NO - Determining the actual request and reply end times from the effective Policies is not trivial. Also, when relative timeouts are involved, determining the end times accurately requires knowing exactly when processing of the request began, which is not available to Portable Interceptor implementations. Our ORB provides extensions to PI that provide these end time attbitutes, and our customers find them useful.They would be more useful if they were portable. 4290 - YES 4554 - YES 5333 - NO - This whole notion of passing in a 'len' param with the DII was completely useless even with the original C mapping. There is no justification for the programmer to have to calculate a value that the ORB could calculate itself, but which the ORB generally doesn't even need. If any changes are going to be made to the definition of the 'len' param, I'd much rather see them remove any sematics from the core and instead delegate this to the language mappings. 5663 - YES 5664 - YES 5672 - YES R3 - YES - Assuming the changes are straightforward. R4 - YES - There should never be a need to copy the slot data during server side processing of a request, and the same slot data should be visible via TSC and RSC for a particular request. The data is associated with the request for the duration, and with threads during upcalls into application level code. We do not want to add any further constraints on what threads the ORB might use to make upcalls into application level code, just clarify that the same slot data that is accessible via the RSC is accessable as TSC during these upcalls. -Bob Jishnu Mukerji wrote: Folks, Vote 8 of the CORBA Core RTF is now available at: http://cgi.omg.org/pub/orbrev/votes/corba_rtf_vote_8.html It is due on November 26, so you have a week to vote on it. Please do vote early and vote often. As usual if you do vote often, only the last vote cast by you will count. Thanks, Jishnu.