Issue 4291: Interceptors and the Java "Local Optimized" stubs (interceptors-rtf) Source: International Business Machines (Mr. Tim Baldwin, tim_baldwin(at)uk.ibm.com) Nature: Uncategorized Issue Severity: Summary: What should happen with Interceptors when Java stubs take the "local optimized" path? This can happen when the client and server both share the same ORB and, if so, the client can make a direct method call to a servant object. The stubs contain code like this: public int ExampleMethod(int i) { if ( !this._is_local() ) { ... // Non-local case ... else { org.omg.CORBA.portable.ServantObject so = _servant_preinvoke("ExampleMethod",_opsClass); if (so == null) ... // Non-local after all ... try { ((ExampleOperations)_so.servant).ExampleMethod(i); return; } finally ( _servant_postinvoke(_so); } } } Should interceptors be driven when this local route is taken? It is an ORB-mediated invocation so the answer ought to be yes, but I'm not sure it really makes a lot of sense. Since client and servant are running in the same thread interceptors would not be needed to transfer thread-context around. And since there is no actual GIOP request/repsonse flow, there is no request_id or service_contexts or many of the other things interceptors normally deal with. This could all be simulated but then the "local optimized" path would become a lot less optimized, and where should the interception points be driven? The _servant_preinvoke() would probably drive send_request, receive_request_service_contexts and receive_request, but the return set (send_reply/send_exception and receive_reply/receive_exception) look harder; _preinvoke is too early and _postinvoke is really too late. Of course a simple solution from an implementation point of view is just to make the _is_local() test always return false if we have request interceptors registered. But this seems to be avoiding the issue. Resolution: Close issue no change. This is a duplicate of java2idl-rtf issue 3754 Revised Text: Actions taken: May 1, 2001: received issue April 26, 2010: closed issue; Duplicate or Merged Discussion: End of Annotations:===== From: tim_baldwin@uk.ibm.com Received: from d06mta10.portsmouth.uk.ibm.com (d06mta09_cs0 [9.180.35.6]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.96) with SMTP id OAA214922 for ; Tue, 1 May 2001 14:20:36 +0100 Received: by d06mta10.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A3F.00494A81 ; Tue, 1 May 2001 14:20:32 +0100 X-Lotus-FromDomain: IBMGB To: interceptors-rtf@omg.org Message-ID: <80256A3F.00494A52.00@d06mta10.portsmouth.uk.ibm.com> Date: Tue, 1 May 2001 14:21:31 +0100 Subject: Interceptors and the Java "Local Optimized" stubs Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: OGM!!QU?e9ZJD!!XH-e9 What should happen with Interceptors when Java stubs take the "local optimized" path? This can happen when the client and server both share the same ORB and, if so, the client can make a direct method call to a servant object. The stubs contain code like this: public int ExampleMethod(int i) { if ( !this._is_local() ) { ... // Non-local case ... else { org.omg.CORBA.portable.ServantObject so = _servant_preinvoke("ExampleMethod",_opsClass); if (so == null) ... // Non-local after all ... try { ((ExampleOperations)_so.servant).ExampleMethod(i); return; } finally ( _servant_postinvoke(_so); } } } Should interceptors be driven when this local route is taken? It is an ORB-mediated invocation so the answer ought to be yes, but I'm not sure it really makes a lot of sense. Since client and servant are running in the same thread interceptors would not be needed to transfer thread-context around. And since there is no actual GIOP request/repsonse flow, there is no request_id or service_contexts or many of the other things interceptors normally deal with. This could all be simulated but then the "local optimized" path would become a lot less optimized, and where should the interception points be driven? The _servant_preinvoke() would probably drive send_request, receive_request_service_contexts and receive_request, but the return set (send_reply/send_exception and receive_reply/receive_exception) look harder; _preinvoke is too early and _postinvoke is really too late. Of course a simple solution from an implementation point of view is just to make the _is_local() test always return false if we have request interceptors registered. But this seems to be avoiding the issue. Regards, Tim - - - Tim Baldwin, Java Technology Centre, IBM UK Labs, Hursley Email: Tim Baldwin/UK/IBM@IBMGB, baldwint@uk.ibm.com Tel: +44-(0)1962-815749 Date: Tue, 01 May 2001 08:03:16 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: tim_baldwin@uk.ibm.com CC: interceptors-rtf@omg.org Subject: Re: Interceptors and the Java "Local Optimized" stubs References: <80256A3F.00494A52.00@d06mta10.portsmouth.uk.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: E3nd9*GQe9jC cc: interceptors-rtf@omg.org Message-ID: <80256A4F.0051DC44.00@d06mta10.portsmouth.uk.ibm.com> Date: Thu, 17 May 2001 15:55:08 +0100 Subject: Re: Interceptors and the Java "Local Optimized" stubs Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: %fSd9`Rkd9Wefd9B8Ke9 Harold, I wasn't really meaning to suggest that these type of calls are not ORB-mediated. I was just raising a concern that, it seemed to me, when such a colocated call takes place with interceptors involved there is likely to be quite a lot of work involved: both in the ORB itself (as it simulates an environment into which interceptors can manipulate service contexts and PI currents) and in interceptors themselves as they, perhaps, extract thread-specific information, marshal it up into (simulated) service contexts, unmarshal it again and reset it into the self same thread they got it from in the first place. This seems like a lot of overhead for what is meant to be an very fast, optimised route. I was wondering if it might be worth providing some indication to the interceptors that this route was being taken so they could avoid unnecessary work? Perhaps even going so far as to disallow service context manipulation in this instance? I had intended this for comments/discussion at this stage, rather than as an actual issue. Regards, Tim - - - Tim Baldwin, Java Technology Centre, IBM UK Labs, Hursley Email: Tim Baldwin/UK/IBM@IBMGB, baldwint@uk.ibm.com Tel: +44-(0)1962-815749 Harold Carr on 01/05/2001 16:03:16 Please respond to Harold Carr To: Tim Baldwin/UK/IBM@IBMGB cc: interceptors-rtf@omg.org Subject: Re: Interceptors and the Java "Local Optimized" stubs Hello Tim, I think that colocated calls are ORB mediated since the involve the POA. That said, there are problems with the colocated path in stubs. I raised them with the java2idl rtf last July. Check out issue 3754. It essentially points out that it is impossible to determine which ending point to call when taking the "local" optimization. I haven't raised an idl2java issue, but the problem occurs there too. Cheers, Harold Date: Thu, 17 May 2001 11:55:53 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: tim_baldwin@uk.ibm.com CC: Harold Carr , interceptors-rtf@omg.org Subject: Re: Interceptors and the Java "Local Optimized" stubs References: <80256A4F.0051DC44.00@d06mta10.portsmouth.uk.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: [d2!!hhZ!!RBld9'TKe9 Its essential that the client and server contexts in a collocated invocation have distinct states for their Current objects. Otherwise, modifications to Currents made in a servant would be propagated back to the client in the collocated invocation case, but not in the remote invocation case, breaking location transparency. For example, if the servant uses the PolicyCurrent to set policies at the thread level, this must not effect the collocated client. If we were to disallow service context manipulation for portable interceptors when collocated, we'd have to provide an alternative mechanism for state to be propagated from the client context to the server context. The ORB I work on does have optimizations for this kind of thing in its native interceptor APIs, but its not clear that such optimizations would apply to all ORB architectures, and therefore they might not be appropriate for Portable Interceptors. -Bob tim_baldwin@uk.ibm.com wrote: > > Harold, > > I wasn't really meaning to suggest that these type of calls are not > ORB-mediated. I was just raising a concern that, it seemed to me, when > such a colocated call takes place with interceptors involved there is > likely to be quite a lot of work involved: both in the ORB itself (as it > simulates an environment into which interceptors can manipulate service > contexts and PI currents) and in interceptors themselves as they, perhaps, > extract thread-specific information, marshal it up into (simulated) service > contexts, unmarshal it again and reset it into the self same thread they > got it from in the first place. > > This seems like a lot of overhead for what is meant to be an very fast, > optimised route. I was wondering if it might be worth providing some > indication to the interceptors that this route was being taken so they > could avoid unnecessary work? Perhaps even going so far as to disallow > service context manipulation in this instance? > > I had intended this for comments/discussion at this stage, rather than as > an actual issue. > > Regards, Tim > - - - > Tim Baldwin, Java Technology Centre, IBM UK Labs, Hursley > Email: Tim Baldwin/UK/IBM@IBMGB, baldwint@uk.ibm.com > Tel: +44-(0)1962-815749 > > Harold Carr on 01/05/2001 16:03:16 > > Please respond to Harold Carr > > To: Tim Baldwin/UK/IBM@IBMGB > cc: interceptors-rtf@omg.org > Subject: Re: Interceptors and the Java "Local Optimized" stubs > > Hello Tim, > > I think that colocated calls are ORB mediated since the involve the > POA. That said, there are problems with the colocated path in stubs. I > raised them with the java2idl rtf last July. Check out issue 3754. It > essentially points out that it is impossible to determine which ending > point to call when taking the "local" optimization. I haven't raised an > idl2java issue, but the problem occurs there too. > > Cheers, > Harold