Sender: jbiggar@corvette.floorboard.com Message-ID: <39173C88.5BE31B06@floorboard.com> Date: Mon, 08 May 2000 15:15:36 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org, interceptors-ftf@omg.org Subject: Detail lacking in when request interceptors are called Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: e From: Harold Carr To: interceptors-ftf@omg.org Subject: Issue 3599: Detail lacking in when request interceptors are called Content-Type: text X-UIDL: ,e>e9U'~!!(>^!!D!5e9 No one has responded to this issue. Does anyone have anything on this we can put to a vote or should we just leave it unresolved? Cheers, Harold Reply-To: From: "Nick Sharman" To: "Harold Carr" , Cc: Subject: RE: Issue 3599: Detail lacking in when request interceptors are called Date: Thu, 20 Jul 2000 12:44:07 +0100 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <200007191826.LAA22107@shorter.eng.sun.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ;~Vd9nJKe9FU?!!!'3!! Harold, Jon, > -----Original Message----- > From: Harold Carr [mailto:harold.carr@eng.sun.com] > Sent: Wednesday, July 19, 2000 7:26 PM > To: interceptors-ftf@omg.org > Subject: Issue 3599: Detail lacking in when request interceptors are > called > > > > No one has responded to this issue. Does anyone have anything on this > we can put to a vote or should we just leave it unresolved? > > Cheers, > Harold > > I think there are two separate issues here, AMI and DII. I think 21.3.7.2 deals with AMI, not DII. I'm not an AMI expert, so someone else can comment. For DII, however, I think there should be just ONE request and ONE reply, and so the relevant client-side interceptors should be called just once each. I agree with Jon that the receive_reply/other/exception interceptors should be called from 'inside' get_(next_)response; if they happen before that, then of course the ORB won't know which thread the call be made on! It might be worth pointing this out in the text, though the necessity appears to flow from point 10 in section 21.4.4.5: 10. The client receives the reply. The Interceptors may read the service contexts associated with the reply. They also have readonly access to the RSC was seen by the send interception points. So here's a proposal for 3599: * Append the following text to bullet point 10 in 21.4.4.5: (Note: in order that the correct RSC is available when handling a reply for a DII call, the receive interception points must be invoked from within Request::get_response or ORB::get_next_response.) Regards Nick Reply-To: From: "Nick Sharman" To: "Harold Carr" , Cc: Subject: RE: Issue 3599: Detail lacking in when request interceptors are called Date: Thu, 20 Jul 2000 14:14:16 +0100 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: %@@e98god9G^~e9!_:!! On rereading my proposal: > -----Original Message----- > > ...(snipped)... > > 10. The client receives the reply. The Interceptors may read the >service > contexts associated with the reply. They also have readonly > access to > the RSC was seen by the send interception points. > > So here's a proposal for 3599: > > * Append the following text to bullet point 10 in 21.4.4.5: > > (Note: in order that the correct RSC is available when >handling a > reply for a DII call, the receive interception points must > be invoked > from within Request::get_response or ORB::get_next_response.) > it seems that the original bullet point 10 is wrong in the DII case; we don't want the RSC of the Request::send / ORB::send_requests call, as seen by the send interception points. I'd like to withdraw that proposal and substitute: * Replace the third paragraph of section 21.4.4.5, currently: On an operation invocation, the flow proceeds as follows: by On a synchronous operation invocation, the flow proceeds as follows: * After bullet point 11, add the following paragraph: On a deferred synchronous invocation via the DII, the flow proceeds similarly, except that at stage (10), the RSC is a copy of the TSC for the relevant call of Request::get_response or ORB::get_next_response. Regards Nick From: Jeffrey Mischkinsky Message-Id: <200007202259.PAA12332@wheel.dcn.davis.ca.us> Subject: Re: Issue 3599: Detail lacking in when request interceptors are called To: nick.sharman@peerlogic.com Date: Thu, 20 Jul 2000 15:59:13 -0700 (PDT) Cc: harold.carr@eng.sun.com (Harold Carr), jon@floorboard.com, interceptors-ftf@omg.org In-Reply-To: from "Nick Sharman" at Jul 20, 2000 12:44:07 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: >5T!!BHI!!9C#!!&3d!! 'Nick Sharman' writes: > > Harold, Jon, > > > -----Original Message----- > > From: Harold Carr [mailto:harold.carr@eng.sun.com] > > Sent: Wednesday, July 19, 2000 7:26 PM > > To: interceptors-ftf@omg.org > > Subject: Issue 3599: Detail lacking in when request interceptors are > > called > > > > > > > > No one has responded to this issue. Does anyone have anything on this > > we can put to a vote or should we just leave it unresolved? > > > > Cheers, > > Harold > > > > > I think there are two separate issues here, AMI and DII. I think 21.3.7.2 > deals with AMI, not DII. I'm not an AMI expert, so someone else can > comment. > > For DII, however, I think there should be just ONE request and ONE reply, > and so the relevant client-side interceptors should be called just once > each. I think the same is true for AMI (ignoring the router-in-the-middle invocations). Even with TII, the "last hop" in either direction is a regular synch invocation. With AMI and polling the client model looks a lot like DII. With callback I think we just have to identify when the interceptors should be called. jeff > I agree with Jon that the receive_reply/other/exception interceptors > should be called from 'inside' get_(next_)response; if they happen > before > that, then of course the ORB won't know which thread the call be > made on! > It might be worth pointing this out in the text, though the > necessity > appears to flow from point 10 in section 21.4.4.5: > > 10. The client receives the reply. The Interceptors may read the > service > contexts associated with the reply. They also have readonly > access to > the RSC was seen by the send interception points. > > So here's a proposal for 3599: > > * Append the following text to bullet point 10 in 21.4.4.5: > > (Note: in order that the correct RSC is available when > handling a > reply for a DII call, the receive interception points must be > invoked > from within Request::get_response or ORB::get_next_response.) > > Regards > Nick > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Wed, 06 Nov 2002 17:41:56 -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: Issue 3599 Discussion I dug through the archive and came up with this partial proposed resolution. Is this headed in the right direction? What else needs to be done for this one? Thanks, Jishnu. _________________________________________________________________ Issue 3599: Detail lacking in when request interceptors are called (interceptors-rtf) Click http://cgi.omg.org/issues/issue3599.txt for this issue's archive. Source: Floorboard Software (Mr. Jonathan Biggar, jon@floorboard.com) Nature: Uncategorized Issue Severity: Summary: I set out reading ptc/2000-04-05 to answer a question: how could a client interceptor for the OTS implement the proper behavior for the DII get_response or get_next_response operations that require the WrongTransaction to be raised if the current thread is not properly associated with the same transaction as the request. I wasn't able to answer this question authoritatively, because there is nothing in the Portable Interceptors Chapter that indicates the proper time sequencing of when the client side request interceptor operations are invoked in relation to the use of the DII (or the AMI_ messaging interfaces either.) ....snip ...... Resolution: Clarify as suggested my Nick Sharman in the archive Revised Text: In formal/02-06-01 make the following changes: 1. Replace the last sentence of the second paragraph of section 21.4.4.5, currently: "On an operation invocation, the flow proceeds as follows:" by "On a synchronous operation invocation, the flow proceeds as follows:" 2. After bullet point 11, add the following paragraph: " On a deferred synchronous invocation via the DII, the flow proceeds similarly, except that at stage (10), the RSC is a copy of the TSC for the relevant call of Request::get_response or ORB::get_next_response." Note: We need to say something specific about AMI or agree that deferred synchronous in case of AMI is the same as for DII as far as this goes, in which case we can remove the phrase "via the DII" in item 2 above. Sender: jbiggar@Resonate.com Date: Wed, 06 Nov 2002 15:31:04 -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: Issue 3599 Discussion Jishnu Mukerji wrote: > > I dug through the archive and came up with this partial proposed > resolution. Is this headed in the right direction? What else needs to be > done for this one? See comments below... > Issue 3599: Detail lacking in when request interceptors are called > (interceptors-rtf) > > Click http://cgi.omg.org/issues/issue3599.txt for this issue's > archive. > Source: Floorboard Software (Mr. Jonathan Biggar, > jon@floorboard.com) > Nature: Uncategorized Issue > Severity: > Summary: > I set out reading ptc/2000-04-05 to answer a question: how could a > client interceptor for the OTS implement the proper behavior for the > DII > get_response or get_next_response operations that require the > WrongTransaction to be raised if the current thread is not > properly associated with the same transaction as the request. > > I wasn't able to answer this question authoritatively, because there > is > nothing in the Portable Interceptors Chapter that indicates the > proper > time sequencing of when the client side request interceptor > operations > are invoked in relation to the use of the DII (or the AMI_ > messaging interfaces either.) > > ....snip ...... > > Resolution: Clarify as suggested my Nick Sharman in the archive > > Revised Text: > In formal/02-06-01 make the following changes: > > 1. Replace the last sentence of the second paragraph of section > 21.4.4.5, currently: > > "On an operation invocation, the flow proceeds as follows:" > > by > > "On a synchronous operation invocation, the flow proceeds as > follows:" So far so good. > 2. After bullet point 11, add the following paragraph: > > " On a deferred synchronous invocation via the DII, the flow proceeds > similarly, except that at stage (10), the RSC is a copy of the TSC for > the relevant call of Request::get_response or ORB::get_next_response." I don't think this is correct, since it would mean that the behavior of the RSC would change depending on whether it was a normal synchronous or a deferred synchronous or AMI call. My understanding is that the contents of the RSC is fixed and constant for the lifetime of the invocation at the point where the invocation is initiated. This does mean that it's more difficult (or infeasible) to implement a lazy copy of the TSC to the RSC at invocation time for DII or AMI poller calls. > Note: We need to say something specific about AMI or agree that deferred > synchronous in case of AMI is the same as for DII as far as this goes, > in which case we can remove the phrase "via the DII" in item 2 above. The same behavior should be exhibited for DII or sendp_ invocations. sendc_ invocations are different. That being said, I think the call flow for a DII or sendp_ invocation needs to be beefed up in 21.3.7.3. We should add this as the third bullet item of the first bullet list in 21.3.7.3: "o For a DII deferred synchronous invocation or AMI invocation using the polling model, send_request is followed by receive_other (when the invocation is successfully initiated) or receive_exception (if the invocation could not be initiated)." and change the last two bullets where it says "TII polls" to "DII polls (using Request::get_response or ORB::get_next_response) or AMI polls (using valuetypes derived from Messaging::Poller). We also need yet another bullet for callbacks: "o for AMI invocations using the callback model, send_request is followed by receive_other (when the invocation is succesfully initiated) or receive_exception (if the invocation could not be initiated). Any reply is treated as a separate invocation on the callback handler object. We also ought to change the text in 21.3.12.10 for the receive_other bullet, where it says "SUCCESSFUL means an asynchronous request returned successfully.", replace it with "SUCCESSFUL means an asychronous request has been successfully initiated." As a note, this partially resolves issue #5743, since the interceptor can check inside the send_poll interception point that the RSC transaction context is compatible with the TSC transaction context. It still doesn't solve the second part of that issue, where there is no way for the interceptor to raise CORBA::WrongTransaction. I think the best way to resolve that one is to define a new minor exception code for BAD_INV_ORDER that the ORB can catch and transform into CORBA::WrongTransaction. So why don't we combine #5743 with this one and fix them together. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jbiggar@Resonate.com Date: Wed, 06 Nov 2002 16:00:47 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Issue 3599 Discussion Jishnu Mukerji wrote: > > Lets resolve 5743 and this one together then. I guess I can consolidate > your comments into a revised resolution for further discussion. I will > do that sometime tomorrow. > > See comment inline... See responses inline: > > > Revised Text: > > > In formal/02-06-01 make the following changes: > > > > > > 1. Replace the last sentence of the second paragraph of section > > > 21.4.4.5, currently: > > > > > > "On an operation invocation, the flow proceeds as follows:" > > > > > > by > > > > > > "On a synchronous operation invocation, the flow proceeds as > > > follows:" > > > > So far so good. > > > > > 2. After bullet point 11, add the following paragraph: > > > > > > " On a deferred synchronous invocation via the DII, the flow > > > proceeds > > > similarly, except that at stage (10), the RSC is a copy of the > > > TSC for > > > the relevant call of Request::get_response or > > > ORB::get_next_response." > > > > I don't think this is correct, since it would mean that the > > > behavior of > > the RSC would change depending on whether it was a normal > > > synchronous or > > a deferred synchronous or AMI call. My understanding is that the > > contents of the RSC is fixed and constant for the lifetime of the > > invocation at the point where the invocation is initiated. This > > > does > > mean that it's more difficult (or infeasible) to implement a lazy > > > copy > > of the TSC to the RSC at invocation time for DII or AMI poller > > > calls. > > So are you suggesting that we should simply remove item 2 in toto? > > > Do > the additions that you propose below cover all bases then? Yes, although I just thought of another problem. What is the RSC when using a PersistentPoller? Since it is a valuetype that can be passed from one process to another, the RSC obviously can't be the same in the other process as at the original invocation point. Anybody have any bright ideas for this one? Should it be empty? A copy of the TSC at the poll point? Change MessageRouting:PersistentRequest to have an attribute that provides access to a copy of the RSC, and PersistentRequestRouter::create_persistent_request to have the RSC as an "in" argument? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 14 Nov 2002 16:28:43 -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 3599 Here is a proposed resolution based on inputs from Nick Sharman and Jon Biggar. Please verify and propose imporvements, absent which this will appear in a vote in the near future. Thanks, Jishnu. ______________________________________________________________________________ Issue 3599: Detail lacking in when request interceptors are called (interceptors-rtf) Click http://cgi.omg.org/issues/issue3599.txt for this issue's archive. Source: Floorboard Software (Mr. Jonathan Biggar, jon@floorboard.com) Nature: Uncategorized Issue Severity: Summary: See Archive http://cgi.omg.org/issues/issue3599.txt Resolution: Clarify as suggested in the archive. Also fix 5743 with this The basic fix for this issue consisting of items 1 through 5 below fixes item 2 of 5743 since the interceptor can now check inside the send_poll interception point that the RSC transaction context is compatible with the TSC transaction context. Items 6 through 9 fixes item 1 of issue 5743. Revised Text: In formal/02-06-01 make the following changes: 1. Replace the last sentence of the second paragraph of section 21.4.4.5, currently: "On an operation invocation, the flow proceeds as follows:" by "On a synchronous operation invocation, the flow proceeds as follows:" 2. In section 21.3.7.3 insert the following as the third bullet item in the first bullet list: "o For a DII deferred synchronous invocation or AMI invocation using the polling model, send_request is followed by receive_other (when the invocation is successfully initiated) or receive_exception (if the invocation could not be initiated)." 3. In the two following bullets replace the phrase "TII polls" by: "DII polls (using Request::get_response or ORB::get_next_response) or AMI polls (using valuetypes derived from Messaging::Poller)" 4. Append the following bullet to the first bullet list (i.e. in the new first bullet list this will be the fifth bullet): "o for AMI invocations using the callback model, send_request is followed by receive_other (when the invocation is succesfully initiated) or receive_exception (if the invocation could not be initiated). Any reply is treated as a separate invocation on the callback handler object." 5. In section 21.3.12.10 in the bullet for receive_other replace the phrase that reads: "SUCCESSFUL means an asynchronous request returned successfully." by "SUCCESSFUL means an asychronous request has been successfully initiated." 6. For fixing 5743 item 1. define a new minor code X for BAD_INV_ORDER which says: "Transaction context of request and client threads do not match in interceptor." 7. Append the following paragraph to section 21.3.7.2 "Additional Client-side details": "If during receive_reply the transaction contexts in the TSC and RSC do not match then raise the system exception BAD_INV_ORDER with standard minor code X". 8. Append the following to the second paragraph in section 7.2.7 "get_response": "If a BAD_INV_ORDER exception with standard minor code X is recieved it shall be trapped and a WrongTransaction shall be returned to the caller." 9. Append the following to the third paragraph in section 7.3.2 "get_next_response": "If a BAD_INV_ORDER exception with standard minor code X is recieved it shall be trapped and a WrongTransaction shall be returned to the caller." 10. Fix an old pre-exisitng bug in section 4.2 IDL for ORB. Change the IDL specification for get_next_response to read: void get_next_response ( out Request req ) raises (WrongTransaction); This is just an editorial change since the IDL is correct in section 7.3.2. Actions taken: Incorporate changes and close this issue and 5743 Date: Mon, 25 Nov 2002 17:30:54 -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 , Juergen Boldt Cc: corba-rtf@omg.org Subject: Re: Issue 3599 Discussion Jonathan Biggar wrote: > > Yes, although I just thought of another problem. What is the RSC when > using a PersistentPoller? Since it is a valuetype that can be passed > from one process to another, the RSC obviously can't be the same in the > other process as at the original invocation point. > > Anybody have any bright ideas for this one? Should it be empty? A copy > of the TSC at the poll point? Change MessageRouting:PersistentRequest > to have an attribute that provides access to a copy of the RSC, and > PersistentRequestRouter::create_persistent_request to have the RSC as an > "in" argument? Let us raise this as a separate issue and resolve it separately. Juergen, a new issue for this one please? Jishnu.