Issue 3524: What if the target application code raises ForwardRequest? (interceptors-rtf) Source: International Business Machines (Mr. Russell Butek, ) Nature: Uncategorized Issue Severity: Summary: Should the ORB care whether ForwardRequest is raised by an interceptor or by the target application code? If no, then the client code will look a bit odd: void proc () raises (PortableInterceptor::ForwardRequest); because the client will have to catch this exception even though this exception will never get to the client. If yes, then we must specifically restrict the meaning of ForwardRequest to something like: "this exception will only cause a location forward if raised by an interceptor." Resolution: resolved Revised Text: Retry behavior only occurs from an ORB call to an interceptor. Make the following clarifications to ptc/00-03-03, section 21.3.15 Revised Text: Add the following text to the end of the first paragraph of this section: This behavior of causing a retry only occurs if the ORB receives a ForwardRequest from an interceptor. If ForwardRequest is raised anywhere else it is pass through the ORB as is normal for a user exception. And change the first sentence of the second paragraph from: If an Interceptor raises a ForwardRequest exception, no other Interceptors are called for that interception point. to: If the ORB receives a ForwardRequest exception in response to a call of an interceptor, no other Interceptors are called for that interception point. Actions taken: March 30, 2000: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568B2.007ABFF1.00@d54mta08.raleigh.ibm.com> Date: Thu, 30 Mar 2000 16:12:18 -0600 Subject: What if the target application code raises ForwardRequest? Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: _CRd9Acf!!GU6!!ZT`d9 I think I know the answer to this, but I want to survey everyone. Should the ORB care whether ForwardRequest is raised by an interceptor or by the target application code? If no, then the client code will look a bit odd: void proc () raises (PortableInterceptor::ForwardRequest); because the client will have to catch this exception even though this exception will never get to the client. If yes, then we must specifically restrict the meaning of ForwardRequest to something like: "this exception will only cause a location forward if raised by an interceptor." What do y'all think? Russell Butek butek@us.ibm.com From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: What if the target application code raises ForwardRequest? Date: Thu, 30 Mar 2000 18:16:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: )BG!!RKS!!KZ^!!-1 From: butek@us.ibm.com [mailto:butek@us.ibm.com] > I think I know the answer to this, but I want to survey everyone. > > Should the ORB care whether ForwardRequest is raised by an > interceptor or > by the target application code? > > > If no, then the client code will look a bit odd: > > void proc () raises (PortableInterceptor::ForwardRequest); > > because the client will have to catch this exception even though > this > exception will never get to the client. clients never have to catch either of these exceptions. They are both thrown by user written code and caught by orb code. Which one is permitted to be thrown is part of the declaration of a particular operation. PortableServer::ForwardRequest can be thrown only from incarnate and preinvoke. PortableInterceptor::ForwardRequest can be thrown only from the various interceptor calls. It is up to the orb to do the right thing when these are raised. > > > If yes, then we must specifically restrict the meaning of > ForwardRequest to > something like: "this exception will only cause a location forward > if > raised by an interceptor." This would be true in any case. Unless of course somebody declares their own operations that take this exception. That would be stupid, and then it would be their responsibility to take appropriate action if it was thrown. (I don't think there is any portable way to do this unless the interface is itself called from inside incarnate or preinvoke. I think you are imagining trying to cause a forward from within the user code implementing an operation. There currently is no portable way to do that. (I wanted to do exactly that recently. I was able to do it with effort, but in an entirely proprietary way.) > > What do y'all think? I think you are pretending to be a Texan! :-) (I didn't notice that accent when I talked to you in Denver.) Paul Date: Thu, 30 Mar 2000 19:56:42 -0330 From: Matthew Newhook To: butek@us.ibm.com Cc: interceptors-ftf@omg.org Subject: Re: What if the target application code raises ForwardRequest? Message-ID: <20000330195642.D6346@ooc.com> References: <852568B2.007ABFF1.00@d54mta08.raleigh.ibm.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <852568B2.007ABFF1.00@d54mta08.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii X-UIDL: JO_!!,+$e9W(4!!=Wgd9 Hi Russell, On Thu, Mar 30, 2000 at 04:12:18PM -0600, butek@us.ibm.com wrote: > > > I think I know the answer to this, but I want to survey everyone. > > Should the ORB care whether ForwardRequest is raised by an > interceptor or > by the target application code? > > > If no, then the client code will look a bit odd: > > void proc () raises (PortableInterceptor::ForwardRequest); > > because the client will have to catch this exception even though > this > exception will never get to the client. Where is this? In the servant code (ie: on the server side)? Or the client code? Either way, I'm not sure I understand. In both cases the ForwardRequest exception should be caught and handled by the ORB runtime. On the server side (assuming GIOP) a GIOP location forward reply should be sent and on the client side, assuming implicit rebinding, then the effective IOR should be exchanged with the forwarded one. Either way client code (that is code written by the end-user) will never see this. > If yes, then we must specifically restrict the meaning of ForwardRequest to > something like: "this exception will only cause a location forward if > raised by an interceptor." > > What do y'all think? > > Russell Butek > butek@us.ibm.com Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: Paul Kyzivat cc: interceptors-ftf@omg.org Message-ID: <852568B3.004C0C24.00@d54mta08.raleigh.ibm.com> Date: Fri, 31 Mar 2000 07:42:09 -0600 Subject: RE: What if the target application code raises ForwardRequest? Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: %o8!!%jFe9,bD!!~9"!! Paul Kyzivat on 03/30/2000 05:16:13 PM > > > > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > > > I think I know the answer to this, but I want to survey everyone. > > > > Should the ORB care whether ForwardRequest is raised by an > > interceptor or > > by the target application code? > > > > > > If no, then the client code will look a bit odd: > > > > void proc () raises (PortableInterceptor::ForwardRequest); > > > > because the client will have to catch this exception even though this > > exception will never get to the client. > > clients never have to catch either of these exceptions. They are both thrown > by user written code and caught by orb code. Which one is permitted to be > thrown is part of the declaration of a particular operation. > > PortableServer::ForwardRequest can be thrown only from incarnate and > preinvoke. > > PortableInterceptor::ForwardRequest can be thrown only from the various > interceptor calls. The spec doesn't say this. > > It is up to the orb to do the right thing when these are raised. > I'm not sure, but I think you misunderstand my question - or I misunderstand your response. I'm only talking about PortableInterceptor::ForwardRequest and the fact that there's nothing that keeps a programmer from defining an IDL operation that raises this exception. There are two aspects to the phrase "raises (PortableInterceptor::ForwardRequest)": 1. The implementation is allowed to raise this exception - no problems here. 2. The caller of the operation must catch this exception - this is the flaky part. The caller must catch this exception but this exception will never be caught. The catch block is needed syntactically but not semantically. > > > > > > If yes, then we must specifically restrict the meaning of > > ForwardRequest to > > something like: "this exception will only cause a location > forward if > > raised by an interceptor." > > This would be true in any case. Unless of course somebody declares > their own > operations that take this exception. That would be stupid, and then > it would > be their responsibility to take appropriate action if it was > thrown. (I > don't think there is any portable way to do this unless the > interface is > itself called from inside incarnate or preinvoke. So you are saying that the ORB SHOULD treat ForwardRequest differently depending on whether it comes from an interceptor or from target code. When it's thrown from an interceptor, it causes a location forward. When it's thrown from the target, it bubbles up to the client. Am I understanding your statement correctly? > > I think you are imagining trying to cause a forward from within the > user > code implementing an operation. There currently is no portable way > to do > that. Why not? ForwardRequest is an available user exception. There is nothing in the spec now that restricts a user from writing IDL that raises it. > > (I wanted to do exactly that recently. I was able to do it with > effort, but > in an entirely proprietary way.) > > > > > What do y'all think? > > I think you are pretending to be a Texan! :-) > (I didn't notice that accent when I talked to you in Denver.) Pretending is right! I've only lived here 2 years and am doing my best to avoid the accent! (Not too hard since Austin is so full of non-Texans that it's not really Texas.) But the English language is missing a good plural form for "you". The Texas form works (I was never comfortable with my grandmother's "yous"). > > Paul > Russell Butek butek@us.ibm.com From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: Matthew Newhook cc: interceptors-ftf@omg.org Message-ID: <852568B3.004CA62D.00@d54mta08.raleigh.ibm.com> Date: Fri, 31 Mar 2000 07:48:42 -0600 Subject: Re: What if the target application code raises ForwardRequest? Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: P__d9+]\!!&i?!!O-9!! Matthew Newhook on 03/30/2000 05:26:42 PM > > > Hi Russell, > > On Thu, Mar 30, 2000 at 04:12:18PM -0600, butek@us.ibm.com wrote: > > > > > > I think I know the answer to this, but I want to survey everyone. > > > > Should the ORB care whether ForwardRequest is raised by an interceptor or > > by the target application code? > > > > > > If no, then the client code will look a bit odd: > > > > void proc () raises (PortableInterceptor::ForwardRequest); > > > > because the client will have to catch this exception even though this > > exception will never get to the client. > > Where is this? In the servant code (ie: on the server side)? Or the > client code? The exception is raised in the servant code. My question is: what happens on the client? > > Either way, I'm not sure I understand. In both cases the > ForwardRequest > exception should be caught and handled by the ORB runtime. On the > server > side (assuming GIOP) a GIOP location forward reply should be sent > and > on the client side, assuming implicit rebinding, then the effective > IOR > should be exchanged with the forwarded one. > > Either way client code (that is code written by the end-user) will > never > see this. That's the way I see it. But here's the reason for this note (and I'm repeating what I said to Paul): There are two aspects to the phrase "raises (PortableInterceptor::ForwardRequest)": 1. The implementation is allowed to raise this exception - no problems here. 2. The caller of the operation must catch this exception - this is the flaky part. The caller must catch this exception but this exception will never be caught. The catch block is needed syntactically but not semantically. If you think the programmer is rather flaky for writing an operation that raises ForwardRequest and deserves the oddity, then you can just tell me to shut up and go away. This is my view, by the way. But if folks think that a ForwardRequest exception raised by the target implementation should actually make its way to the client application, then we've got to talk about this. I think this would be wrong. But if this interpretation can be read into the spec, then perhaps we have to clarify the spec. > > > If yes, then we must specifically restrict the meaning of ForwardRequest to > > something like: "this exception will only cause a location > forward if > > raised by an interceptor." > > > > What do y'all think? > > Russell Butek butek@us.ibm.com Date: Fri, 31 Mar 2000 10:40:09 -0330 From: Matthew Newhook To: butek@us.ibm.com Cc: interceptors-ftf@omg.org Subject: Re: What if the target application code raises ForwardRequest? Message-ID: <20000331104008.A10243@ooc.com> References: <852568B3.004CA62D.00@d54mta08.raleigh.ibm.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <852568B3.004CA62D.00@d54mta08.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii X-UIDL: F]]!![Ygd9Aecd9'Md!! Hi, On Fri, Mar 31, 2000 at 07:48:42AM -0600, butek@us.ibm.com wrote: > >[...] > > Either way client code (that is code written by the end-user) will > never > > see this. > > That's the way I see it. But here's the reason for this note (and > I'm > repeating what I said to Paul): > > There are two aspects to the phrase "raises > (PortableInterceptor::ForwardRequest)": > > 1. The implementation is allowed to raise this exception - no > problems > here. > > 2. The caller of the operation must catch this exception - this is > the > flaky part. The caller must catch this exception but this exception > will > never be caught. The catch block is needed syntactically but not > semantically. > > If you think the programmer is rather flaky for writing an operation > that > raises ForwardRequest and deserves the oddity, then you can just > tell me to > shut up and go away. This is my view, by the way. > > But if folks think that a ForwardRequest exception raised by the > target > implementation should actually make its way to the client > application, then > we've got to talk about this. I think this would be wrong. But if > this > interpretation can be read into the spec, then perhaps we have to > clarify > the spec. Ah, now I understand what you mean :) Certainly for our implementation if the servant code raised this exception then it will get eaten by the ORB runtime and the client will never see it. Personally, I'd like to see it stay that way ;) I guess the same basic issue exists with PortableServer::LocationForward. I'm pretty sure for our ORB the client *would* see this exception (although I'd have to check to be sure). > Russell Butek > butek@us.ibm.com Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: What if the target application code raises ForwardRequest? Date: Fri, 31 Mar 2000 09:30:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: W$Me9nPIe9Y~Be9T;P!! > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > > PortableInterceptor::ForwardRequest can be thrown only from > the various > > interceptor calls. > > The spec doesn't say this. I'm sorry - I was sloppy in my wording. What I meant was explained later. See below. > > > > > > It is up to the orb to do the right thing when these are raised. > > > > I'm not sure, but I think you misunderstand my question - or I > misunderstand your response. I'm only talking about > PortableInterceptor::ForwardRequest and the fact that there's > nothing that > keeps a programmer from defining an IDL operation that raises this > exception. There are two aspects to the phrase "raises > (PortableInterceptor::ForwardRequest)": > > 1. The implementation is allowed to raise this exception - > no problems > here. > > 2. The caller of the operation must catch this exception - > this is the > flaky part. The caller must catch this exception but this > exception will > never be caught. The catch block is needed syntactically but not > semantically. I don't think that the raising of an exception ever guarantees any particular action in response, without taking into consideration the context in which it is thrown. In effect an exception is a variant form of return from a function. Exactly what happens when that form of return occurs *from a particular function* is part of the contract for that function. The fact that ForwardRequest has been raised is simply a piece of information for the caller to consider. It may choose to let one of its callers deal with it my not bothering to catch it at all, or it may catch and handle the exception. Of course the caller may be forced, syntactically, to catch the exception because the caller is not permitted, syntactically, to let it leak out. (In other words, the caller's own signature doesn't permit raising this exception.) But that is the caller's problem. If the caller doesn't know what to do with the exception then it shouldn't be calling a function that raises it. And it would be stupid to declare a new function that raises this exception inless you plan to write a caller that will have a clue what to do with it. > So you are saying that the ORB SHOULD treat ForwardRequest differently > depending on whether it comes from an interceptor or from target code. > When it's thrown from an interceptor, it causes a location > forward. When > it's thrown from the target, it bubbles up to the client. Am I > understanding your statement correctly? No, not really. The ORB should treat ForwardRequest differently (namely catch and do something with it) when *the orb itself* calls the particular operations that the spec itself defines as raising this exception. The behavior that we have ascribed to the ForwardRequest exception is related not to the exception itself, but to the receipt of that exception in the context of those operations. (Namely, PortableServer::ForwardRequest has defined meaning when raised from a call to ServantLocator::preinvoke or ServantActivator::incarnate. PortableInterceptor::ForwardRequest has essentially the same meaning when raised by the relevant interceptor operations (I forget which).) > Why not? ForwardRequest is an available user exception. > There is nothing > in the spec now that restricts a user from writing IDL that raises > it. There is no standard way for user code to modify an object reference in the same way that happens when the orb receives a LOCATION_FORWARD response from giop. Nor is there any standard way, *from within the implementation of an IDL operation*, for user code to cause a LOCATION_FORWARD response to be sent as the response to that operation. I can only think of one kind situation where it would make sense for a user to define a new operation that returns one of these exceptions: Imagine a user written implementation of ServantActivator::incarnate. It could make other invocations in the process of doing its work. One of those operations could be defined to raise LocationForward. This implementation of incarnate could simply permit this to leak through to its caller, resulting in the desired effect. Paul From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: What if the target application code raises ForwardRequest? Date: Fri, 31 Mar 2000 10:00:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: k,P!!=n^d9d4@e9fX^!! > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > But if folks think that a ForwardRequest exception raised by > the target > implementation should actually make its way to the client > application, then > we've got to talk about this. I think this would be wrong. > But if this > interpretation can be read into the spec, then perhaps we > have to clarify > the spec. All the invocations we care about that raise this exception are local. If some user uses this exception as part of a remote invocation then it ought to be processed like any other remote invocation and raised for the caller. Paul From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: Paul Kyzivat cc: interceptors-ftf@omg.org Message-ID: <852568B3.00541D49.00@d54mta08.raleigh.ibm.com> Date: Fri, 31 Mar 2000 09:10:15 -0600 Subject: RE: What if the target application code raises ForwardRequest? Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 251e9,%4!!W?Pe9JS9e9 Ah. We have a difference of opinion here. What you're saying is, effectively this exception (and others presumably? PortableServer::ForwardRequest? ...) is treated one way in local interface and a different way in remotable interfaces. I disagree. If we really want this sort of behaviour, then we should allow the "local" keyword to be applied to exceptions. Until we do that, we'd potentially have to individually assess each user exception defined in OMG and individually state - explicitly - how it behaves. (Yes, I'm exaggerating a bit here, but I'm just trying to make a point against this idea.) Russell Butek butek@us.ibm.com Paul Kyzivat on 03/31/2000 09:00:25 AM To: interceptors-ftf@omg.org cc: Subject: RE: What if the target application code raises ForwardRequest? > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > But if folks think that a ForwardRequest exception raised by > the target > implementation should actually make its way to the client > application, then > we've got to talk about this. I think this would be wrong. > But if this > interpretation can be read into the spec, then perhaps we > have to clarify > the spec. All the invocations we care about that raise this exception are local. If some user uses this exception as part of a remote invocation then it ought to be processed like any other remote invocation and raised for the caller. Paul From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: Matthew Newhook cc: interceptors-ftf@omg.org Message-ID: <852568B3.00516130.00@d54mta08.raleigh.ibm.com> Date: Fri, 31 Mar 2000 08:40:23 -0600 Subject: Re: What if the target application code raises ForwardRequest? Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: bGCe9"eH!!;2b!!8nD!! Matthew Newhook on 03/31/2000 08:10:09 AM > (...snip...) > > Ah, now I understand what you mean :) > > Certainly for our implementation if the servant code raised this exception > then it will get eaten by the ORB runtime and the client will never > see it. > > Personally, I'd like to see it stay that way ;) Yup. Me too! > > I guess the same basic issue exists with > PortableServer::LocationForward. > I'm pretty sure for our ORB the client *would* see this exception > (although I'd have to check to be sure). I'm one of those flaky programmers who wrote a test case with an operation that raises ForwardRequest. I expected a LOCATION_FORWARD to occur and it didn't. It turns out that, if the target raises ForwardRequest, the stream-based skeleton in the Java portable bindings marshals the user exception before control returns to the ORB. So I have to go through the nuisance of reading the ID from the stream and, if it IS a ForwardRequest, unmarshaling it to gather the forwarded object so I can call the send_other list with the appropriate data. What a pain. But I'd rather go through this pain than let the ForwardRequest bubble up to the client. Russell Butek butek@us.ibm.com Reply-To: From: "Nick Sharman" To: Subject: RE: What if the target application code raises ForwardRequest? Date: Fri, 31 Mar 2000 16:50:58 +0100 Message-ID: <001e01bf9b28$e7ecb4b0$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BD95@bos1.noblenet.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: fW0!![\X!!<>Ce9>V9e9 > From: Paul Kyzivat [mailto:paulk@roguewave.com] > > > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > > > But if folks think that a ForwardRequest exception raised by > > the target > > implementation should actually make its way to the client > > application, then > > we've got to talk about this. I think this would be wrong. > > But if this > > interpretation can be read into the spec, then perhaps we > > have to clarify > > the spec. > > All the invocations we care about that raise this exception are local. > If some user uses this exception as part of a remote invocation then it > ought to be processed like any other remote invocation and raised for the > caller. > > Paul > I agree; if the ForwardRequest exception (either the PI or PortableServer version) is part of the user's IDL spec, it should pass through the ORB from the servant to the (probably remote) client. Regards Nick From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: What if the target application code raises ForwardRequest? Date: Fri, 31 Mar 2000 12:54:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: peMe9nS8!!&Tm!!Omf!! See below. Paul > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Ah. We have a difference of opinion here. > > What you're saying is, effectively this exception (and others > presumably? > PortableServer::ForwardRequest? ...) is treated one way in > local interface > and a different way in remotable interfaces. > > I disagree. If we really want this sort of behaviour, then > we should allow > the "local" keyword to be applied to exceptions. Until we do > that, we'd > potentially have to individually assess each user exception > defined in OMG > and individually state - explicitly - how it behaves. (Yes, I'm > exaggerating a bit here, but I'm just trying to make a point > against this idea.) I am not that it is treated differently in local and remote invocations. What I am saying is that the only operations the orb ever calls that could raise this exception are on interfaces that are locally constrained. Now, if we wanted to remove the local constraint on servant managers, then I suppose somebody could try to implement a remote servant manager that threw this exception. In that case, presumably the exception would be marshalled back to the calling orb, and eventually acted upon by the orb. But it would be stupid to remove the local contraint on servant manager. > > Russell Butek > butek@us.ibm.com > > > Paul Kyzivat on 03/31/2000 09:00:25 AM > > To: interceptors-ftf@omg.org > cc: > Subject: RE: What if the target application code raises > ForwardRequest? > > > > > > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > > > But if folks think that a ForwardRequest exception raised by > > the target > > implementation should actually make its way to the client > > application, then > > we've got to talk about this. I think this would be wrong. > > But if this > > interpretation can be read into the spec, then perhaps we > > have to clarify > > the spec. > > All the invocations we care about that raise this exception are > local. > If some user uses this exception as part of a remote > invocation then it > ought to be processed like any other remote invocation and > raised for the > caller. > > Paul > > > Date: Sat, 01 Apr 2000 10:08:15 -0500 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: butek@us.ibm.com CC: Paul Kyzivat , interceptors-ftf@omg.org Subject: Re: What if the target application code raises > ForwardRequest? References: <852568B3.00541D49.00@d54mta08.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: p+'!!mSKe9YL?e9g@X!! I've never seen or heard anything during the relevant RFP submission processes that would have led me to suspect anything unusual in the semantics of these IDL exception declarations. Therefore, I don't suspect an IDL compiler, or the ORB core in general, should have to treat them specially in any way. The IDL declaration just provides the syntax. Its the specifications of the operations in which they are used that attach semantics to the raising of user exceptions declared in IDL. The PortableServer::ForwardRequest exception only should cause a LocationForward response when raised by an operation where that semantic is specified. If its used in other operation declarations, those specifications need to specify the intended handling by the callee. Same thing goes for the PortableInterceptor exceptions. -Bob butek@us.ibm.com wrote: > > Ah. We have a difference of opinion here. > > What you're saying is, effectively this exception (and others > presumably? > PortableServer::ForwardRequest? ...) is treated one way in local > interface > and a different way in remotable interfaces. > > I disagree. If we really want this sort of behaviour, then we > should allow > the "local" keyword to be applied to exceptions. Until we do that, > we'd > potentially have to individually assess each user exception defined > in OMG > and individually state - explicitly - how it behaves. (Yes, I'm > exaggerating a bit here, but I'm just trying to make a point against > this > idea.) > > Russell Butek > butek@us.ibm.com > > Paul Kyzivat on 03/31/2000 09:00:25 AM > > To: interceptors-ftf@omg.org > cc: > Subject: RE: What if the target application code raises > ForwardRequest? > > > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > > > But if folks think that a ForwardRequest exception raised by > > the target > > implementation should actually make its way to the client > > application, then > > we've got to talk about this. I think this would be wrong. > > But if this > > interpretation can be read into the spec, then perhaps we > > have to clarify > > the spec. > > All the invocations we care about that raise this exception are > local. > If some user uses this exception as part of a remote invocation then > it > ought to be processed like any other remote invocation and raised > for the > caller. > > Paul From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: What if the target application code raises ForwardRequest? Date: Mon, 3 Apr 2000 08:41:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ~k*e9'GN!!(XE!!e^a!! I agree with Bob - this is more or less what I have been trying to explain. But I have one minor comment below. Paul > From: Bob Kukura [mailto:kukura@iona.com] > I've never seen or heard anything during the relevant RFP submission > processes that would have led me to suspect anything unusual in the > semantics of these IDL exception declarations. Therefore, I don't > suspect an IDL compiler, or the ORB core in general, should have to > treat them specially in any way. The IDL declaration just > provides the > syntax. Its the specifications of the operations in which > they are used > that attach semantics to the raising of user exceptions declared in > IDL. The PortableServer::ForwardRequest exception only should cause > a > LocationForward response when raised by an operation where > that semantic > is specified. If its used in other operation declarations, those > specifications need to specify the intended handling by the callee. In this case, it isn't the callee, but the caller that has the obligation. (There isn't anything the callee could do other than decide to raise the exception.) The spec is defining an operation that will be called by the ORB and implemented in user code. Certain behavior is mandated on the orb in the case when this exception is raised in this context. Possibly we need to do some work on the specification to make this clear. (But the intent already seemed pretty clear to me.) > Same thing goes for the PortableInterceptor exceptions. Yep. From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568B6.004713A8.00@d54mta08.raleigh.ibm.com> Date: Mon, 3 Apr 2000 07:47:43 -0500 Subject: RE: What if the target application code raises ForwardRequest? Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: cgHe9,*U!!S64e9!\b!! Paul Kyzivat on 04/03/2000 07:41:41 AM > (...snip...) > > The spec is defining an operation that will be called by the ORB and > implemented in user code. Certain behavior is mandated on the orb in > the > case when this exception is raised in this context. > > Possibly we need to do some work on the specification to make this > clear. > (But the intent already seemed pretty clear to me.) > Well, I have to admit that it wasn't clear to me. It's clearer in the POA chapter than the PI chapter, but it's still not very explicit. If this is indeed the intended behaviour - that ForwardRequest causes a location forward ONLY where specified - then we had better make it explicit in the spec. This should probably become an issue. Russell Butek butek@us.ibm.com From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: What if the target application code raises ForwardRequest? Date: Mon, 3 Apr 2000 16:36:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: T+3!!6ZB!!pSkd9Do6e9 Russell - see below. Paul > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Paul Kyzivat on 04/03/2000 07:41:41 AM > > (...snip...) > > > > The spec is defining an operation that will be called by the ORB > and > > implemented in user code. Certain behavior is mandated on > the orb in the > > case when this exception is raised in this context. > > > > Possibly we need to do some work on the specification to > make this clear. > > (But the intent already seemed pretty clear to me.) > > > > Well, I have to admit that it wasn't clear to me. It's > clearer in the POA > chapter than the PI chapter, but it's still not very > explicit. If this is > indeed the intended behaviour - that ForwardRequest causes a > location > forward ONLY where specified - then we had better make it > explicit in the > spec. > > This should probably become an issue. Perhaps it isn't clearly there in black and white, but only by implication... The alternative (what I think you were assuming) is that the orb should notice when this particular exception is being thrown, and somehow cause the invocation it is returning from to be retried with the object reference from the exception. But this doesn't work in the primary use cases (incarnate & preinvoke) because the effect is not on the object that is throwing the exception, but is on a different object. It clearly must be the caller of incarnate that must catch the exception and do something special. If you want to get your mind twisted, consider the case where a servant manager itself is not active, but where the POA that manages the servant manager itself has a servant manager... In that case, in the midst of the preinvoke/incarnate call, another preinvoke/incarnate will be made. If that nested call throws a ForwardRequest, it must affect the proper thing. I am not going to go into the details, unless someone begs. (It is more fun to let people work out what has to happen.) But when you get done, the implications should be clear. Just to anticipate the question - yes, I have tried this. Happily, this case goes away when servant managers are required to be local objects. From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568BD.0068DFD0.00@d54mta08.raleigh.ibm.com> Date: Mon, 10 Apr 2000 13:56:35 -0500 Subject: Issue 3524 proposal Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: -f5!!mYj!!],cd9P6Be9 Here's a proposed clarification of the spec wrt the ForwardRequest exception. I don't necessarily agree with this proposal (and may even vote against it), but I'm trying to get down what the seeming majority seems to think. I believe we have to get the ball rolling here. We have 2 issues that can potentially be voted on, 3 with this one, so when the discussion on this issue - if any - settles down, I'll open a vote. ------------------------------ Section 5.5 ForwardRequest Exception, page 5-53, add the following paragraph at the end: PortableInterceptor::ForwardRequest will only result in a Location Forward action if raised from within an interceptor that is allowed to raise it. If application code raises this exception, it will propagate to the caller like any other user exception. ------------------------------ Russell Butek butek@us.ibm.com From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Issue 3524 proposal Date: Mon, 10 Apr 2000 19:31:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: \,Xd9)+:!!-[\!!f?Z!! I think this is still confusing. I have a different proposal that better captures *my* intent. In the first sentence of the second paragraph of 5.5, replace: "If an Interceptor raises a ForwardRequest exception," with: "If the orb receives a ForwardRequest exception in response to a call of an interceptor," Paul > -----Original Message----- > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Sent: Monday, April 10, 2000 2:57 PM > To: interceptors-ftf@omg.org > Subject: Issue 3524 proposal > > > > > Here's a proposed clarification of the spec wrt the ForwardRequest > exception. I don't necessarily agree with this proposal (and > may even vote > against it), but I'm trying to get down what the seeming > majority seems to > think. I believe we have to get the ball rolling here. We > have 2 issues > that can potentially be voted on, 3 with this one, so when > the discussion > on this issue - if any - settles down, I'll open a vote. > > ------------------------------ > > Section 5.5 ForwardRequest Exception, page 5-53, add the following > paragraph at the end: > > PortableInterceptor::ForwardRequest will only result in a > Location Forward > action if raised from within an interceptor that is allowed > to raise it. > If application code raises this exception, it will propagate > to the caller > like any other user exception. > > ------------------------------ > > Russell Butek > butek@us.ibm.com > > From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568BE.00461E46.00@d54mta08.raleigh.ibm.com> Date: Tue, 11 Apr 2000 07:36:55 -0500 Subject: RE: Issue 3524 proposal Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: E(9!!cQC!!A@&e9YGjd9 Confusing? How? It seems clear to me (of course, since I wrote it I have to admit to bias). I don't see how your proposal is semantically different than the original. In the original, the ORB's receiving of the exception is implied, in your proposal, it is explicit. And it says nothing about what happens if ForwardRequest were thrown by an application, which is the question this issue asks. Perhaps I don't yet understand your intent. Rereading the section, I guess I see a possibility of making the statement clearer. Instead of creating a new paragraph, we could just add the following to the first paragraph (which doesn't preclude your proposal, though I don't find it necessary): This behavior of causing a retry only occurs if the ORB receives a ForwardRequest from an interceptor. If ForwardRequest is raised anywhere else it is treated as a normal user exception. Russell Butek butek@us.ibm.com Paul Kyzivat on 04/10/2000 06:31:59 PM To: interceptors-ftf@omg.org cc: Subject: RE: Issue 3524 proposal I think this is still confusing. I have a different proposal that better captures *my* intent. In the first sentence of the second paragraph of 5.5, replace: "If an Interceptor raises a ForwardRequest exception," with: "If the orb receives a ForwardRequest exception in response to a call of an interceptor," Paul > -----Original Message----- > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Sent: Monday, April 10, 2000 2:57 PM > To: interceptors-ftf@omg.org > Subject: Issue 3524 proposal > > > > > Here's a proposed clarification of the spec wrt the ForwardRequest > exception. I don't necessarily agree with this proposal (and > may even vote > against it), but I'm trying to get down what the seeming > majority seems to > think. I believe we have to get the ball rolling here. We > have 2 issues > that can potentially be voted on, 3 with this one, so when > the discussion > on this issue - if any - settles down, I'll open a vote. > > ------------------------------ > > Section 5.5 ForwardRequest Exception, page 5-53, add the following > paragraph at the end: > > PortableInterceptor::ForwardRequest will only result in a > Location Forward > action if raised from within an interceptor that is allowed > to raise it. > If application code raises this exception, it will propagate > to the caller > like any other user exception. > > ------------------------------ > > Russell Butek > butek@us.ibm.com > > From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Issue 3524 proposal Date: Tue, 11 Apr 2000 11:14:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 4S3e99]%!!d]*!!3n#e9 > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Confusing? How? It seems clear to me (of course, since I > wrote it I have to admit to bias). > > I don't see how your proposal is semantically different than > the original. > In the original, the ORB's receiving of the exception is > implied, in your > proposal, it is explicit. And it says nothing about what happens if > ForwardRequest were thrown by an application, which is the > question this > issue asks. Perhaps I don't yet understand your intent. I thought the original implied the right thing until this discussion was raised. It indicated to me that somebody didn't see the implication, so it needed to be more explicit. It is different because it explicitly says that it is the receipt of the exception in the context of the orb calling the interceptor that causes the forwarding effect. If the interceptor is called in some other context (not clear why anyone would do that, but it is legal) then the forwarding effect does not happen. It says nothing about what happens if the exception is thrown by an application because that is irrelevant. Anybody can throw any exception at any time - the effect is simply that normal exception throwing semantics are followed until somebody catches it. Consider the following cases: 1) orb --> interceptor --> throw ForwardRequest This is the normal case, and causes a forward to happen. 2) orb --> interceptor --> some_function --> throw ForwardRequest Assuming the interceptor allows the exception to leak through, this is equally valid. 3) orb --> servant --> interceptor --> throw ForwardRequest Here, even though the orb is on the call stack, it is currently in the midst of the dispatch of a request to a servant, and is not expecting ForwardRequest. It is the servant that (for some perverse reason) has called the interceptor. In this case, the exception is not going to cause a forward. > > Rereading the section, I guess I see a possibility of making > the statement > clearer. Instead of creating a new paragraph, we could just add the > following to the first paragraph (which doesn't preclude your > proposal, > though I don't find it necessary): > > This behavior of causing a retry only occurs if the ORB receives a > ForwardRequest > from an interceptor. If ForwardRequest is raised anywhere else it > is > treated as a normal user exception. I have no objection to adding this text, as long as you have no objection to mine. My goal is not the precise wording, but rather that there is sufficient wording that everyone has a common understanding of the behavior. I think we do, but I am still not certain. Paul > > Russell Butek > butek@us.ibm.com > > > Paul Kyzivat on 04/10/2000 06:31:59 PM > > To: interceptors-ftf@omg.org > cc: > Subject: RE: Issue 3524 proposal > > > > > I think this is still confusing. > I have a different proposal that better captures *my* intent. > > In the first sentence of the second paragraph of 5.5, replace: > > "If an Interceptor raises a ForwardRequest exception," > > with: > > "If the orb receives a ForwardRequest exception in response > to a call of an interceptor," > > Paul > > > -----Original Message----- > > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > > Sent: Monday, April 10, 2000 2:57 PM > > To: interceptors-ftf@omg.org > > Subject: Issue 3524 proposal > > > > > > > > > > Here's a proposed clarification of the spec wrt the ForwardRequest > > exception. I don't necessarily agree with this proposal (and > > may even vote > > against it), but I'm trying to get down what the seeming > > majority seems to > > think. I believe we have to get the ball rolling here. We > > have 2 issues > > that can potentially be voted on, 3 with this one, so when > > the discussion > > on this issue - if any - settles down, I'll open a vote. > > > > ------------------------------ > > > > Section 5.5 ForwardRequest Exception, page 5-53, add the following > > paragraph at the end: > > > > PortableInterceptor::ForwardRequest will only result in a > > Location Forward > > action if raised from within an interceptor that is allowed > > to raise it. > > If application code raises this exception, it will propagate > > to the caller > > like any other user exception. > > > > ------------------------------ > > > > Russell Butek > > butek@us.ibm.com > > > > > > > From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568BE.00550C81.00@d54mta08.raleigh.ibm.com> Date: Tue, 11 Apr 2000 10:19:58 -0500 Subject: RE: Issue 3524 proposal Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: \c?e9"9X!!&b/e9M0ad9 Ah! I understand now. And I agree. (I hadn't considered the point where someone OTHER than the ORB called an interceptor). So, to consolidate our proposals: ------------------------------------ In ptc/00-03-03, section 21.3.15, change the first paragraph and the first sentence of the second paragraph: The ForwardRequest exception is the means by which an Interceptor can indicate to the ORB that a retry of the request should occur with the new object given in the exception. The permanent flag indicates whether the forward object is to become permanent or used only on the forwarded request. If an Interceptor raises a ForwardRequest exception, no other Interceptors are called for that interception point. ... to: The ForwardRequest exception is the means by which an Interceptor can indicate to the ORB that a retry of the request should occur with the new object given in the exception. The permanent flag indicates whether the forward object is to become permanent or used only on the forwarded request. This behavior of causing a retry only occurs if the ORB receives a ForwardRequest from an interceptor. If ForwardRequest is raised anywhere else it is treated as a normal user exception. If the orb receives a ForwardRequest exception in response to a call of an interceptor, no other Interceptors are called for that interception point. ... ------------------------------------ Do you agree, Paul? Russell Butek butek@us.ibm.com Paul Kyzivat on 04/11/2000 10:14:58 AM To: interceptors-ftf@omg.org cc: Subject: RE: Issue 3524 proposal > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Confusing? How? It seems clear to me (of course, since I > wrote it I have to admit to bias). > > I don't see how your proposal is semantically different than > the original. > In the original, the ORB's receiving of the exception is > implied, in your > proposal, it is explicit. And it says nothing about what happens if > ForwardRequest were thrown by an application, which is the > question this > issue asks. Perhaps I don't yet understand your intent. I thought the original implied the right thing until this discussion was raised. It indicated to me that somebody didn't see the implication, so it needed to be more explicit. It is different because it explicitly says that it is the receipt of the exception in the context of the orb calling the interceptor that causes the forwarding effect. If the interceptor is called in some other context (not clear why anyone would do that, but it is legal) then the forwarding effect does not happen. It says nothing about what happens if the exception is thrown by an application because that is irrelevant. Anybody can throw any exception at any time - the effect is simply that normal exception throwing semantics are followed until somebody catches it. Consider the following cases: 1) orb --> interceptor --> throw ForwardRequest This is the normal case, and causes a forward to happen. 2) orb --> interceptor --> some_function --> throw ForwardRequest Assuming the interceptor allows the exception to leak through, this is equally valid. 3) orb --> servant --> interceptor --> throw ForwardRequest Here, even though the orb is on the call stack, it is currently in the midst of the dispatch of a request to a servant, and is not expecting ForwardRequest. It is the servant that (for some perverse reason) has called the interceptor. In this case, the exception is not going to cause a forward. > > Rereading the section, I guess I see a possibility of making > the statement > clearer. Instead of creating a new paragraph, we could just add the > following to the first paragraph (which doesn't preclude your > proposal, > though I don't find it necessary): > > This behavior of causing a retry only occurs if the ORB receives a > ForwardRequest > from an interceptor. If ForwardRequest is raised anywhere else it > is > treated as a normal user exception. I have no objection to adding this text, as long as you have no objection to mine. My goal is not the precise wording, but rather that there is sufficient wording that everyone has a common understanding of the behavior. I think we do, but I am still not certain. Paul > > Russell Butek > butek@us.ibm.com > > > Paul Kyzivat on 04/10/2000 06:31:59 PM > > To: interceptors-ftf@omg.org > cc: > Subject: RE: Issue 3524 proposal > > > > > I think this is still confusing. > I have a different proposal that better captures *my* intent. > > In the first sentence of the second paragraph of 5.5, replace: > > "If an Interceptor raises a ForwardRequest exception," > > with: > > "If the orb receives a ForwardRequest exception in response > to a call of an interceptor," > > Paul > > > -----Original Message----- > > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > > Sent: Monday, April 10, 2000 2:57 PM > > To: interceptors-ftf@omg.org > > Subject: Issue 3524 proposal > > > > > > > > > > Here's a proposed clarification of the spec wrt the ForwardRequest > > exception. I don't necessarily agree with this proposal (and > > may even vote > > against it), but I'm trying to get down what the seeming > > majority seems to > > think. I believe we have to get the ball rolling here. We > > have 2 issues > > that can potentially be voted on, 3 with this one, so when > > the discussion > > on this issue - if any - settles down, I'll open a vote. > > > > ------------------------------ > > > > Section 5.5 ForwardRequest Exception, page 5-53, add the following > > paragraph at the end: > > > > PortableInterceptor::ForwardRequest will only result in a > > Location Forward > > action if raised from within an interceptor that is allowed > > to raise it. > > If application code raises this exception, it will propagate > > to the caller > > like any other user exception. > > > > ------------------------------ > > > > Russell Butek > > butek@us.ibm.com > > > > > > > From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Issue 3524 proposal Date: Tue, 11 Apr 2000 12:19:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 0UBe9U:Be95%Z!!_kcd9 > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > The ForwardRequest exception is the means by which an Interceptor can > indicate to > the ORB that a retry of the request should occur with the new > object given > in the > exception. The permanent flag indicates whether the forward > object is to > become > permanent or used only on the forwarded request. This > behavior of causing > a retry > only occurs if the ORB receives a ForwardRequest from an > interceptor. If > ForwardRequest is raised anywhere else it is treated as a normal user > exception. > > If the orb receives a ForwardRequest exception in response to > a call of an > interceptor, > no other Interceptors are called for that interception point. ... > > > ------------------------------------ > > Do you agree, Paul? This is fine with me. (Just to pick at nits, saying that ForwardRequest raised anywhere else is treated as a normal user exception implies that it is not treated as a normal user exception when the interceptor is called by the orb. This isn't really true - it is a normal user exception then too. This *is* a normal user exception, conveying some information to a caller, with the caller taking action as a result.) From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: Paul Kyzivat cc: interceptors-ftf@omg.org Message-ID: <852568BE.005A6E76.00@d54mta08.raleigh.ibm.com> Date: Tue, 11 Apr 2000 11:18:48 -0500 Subject: RE: Issue 3524 proposal Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: `YR!!ApG!!,ncd9:`cd9 Paul Kyzivat on 04/11/2000 11:19:16 AM > (Just to pick at nits, saying that ForwardRequest raised anywhere else is > treated as a normal user exception implies that it is not treated as a > normal user exception when the interceptor is called by the orb. This isn't > really true - it is a normal user exception then too. This *is* a normal > user exception, conveying some information to a caller, with the caller > taking action as a result.) Perhaps instead of saying "treated as a normal user exception", it could be rephrased as "passed through the ORB as is normal for a user exception." From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Issue 3524 proposal Date: Tue, 11 Apr 2000 13:26:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: k;"!!;YL!!-e-e9\=T!! > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Perhaps instead of saying "treated as a normal user > exception", it could be > rephrased as "passed through the ORB as is normal for a user > exception." I am satisfied either way. Paul