Issue 3619: Thread context switches (interceptors-rtf) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: the current draft permits receive_request_service_context, receive_request, the operation, and send_reply or send_exception to all run in different threads. This is rather inconvenient, especially for OTS, where I want to to talk to an XA interface from the interception points. The problem is that XA is sensitive to the calling thread and doesn't allow me to, for example, start something in one thread and finish it in another. Now, consider the following: - The POA spec already requires preinvoke, the operation, and postinvoke to run in the same thread. - The sequence of invocations if a servant locator is present for interceptors is: 1) receive_request_service_context 2) preinvoke 3) receive_request 4) operation 5) postinvoke 6) send_reply or send_exception Of these, 2, 4, and 5 must happen in the same thread. Now, what is the likelihood that an interceptor implementation will switch context after preinvoke and before receive_request, only to have to switch back to the original thread after preinvoke and before the operation? Essentially zero, I think. It's a lot harder and a lot less efficient to do that context switch than to not do it. In other words, I don't think we would lose anything if we required that 3 and 4 must run in the same thread. Similarly, an implementation isn't going to do a context switch after 4 (or 5) and before 6, because at point 6 I still must be able to modify the reply context. (If the ORB uses a separate thread to squirt reply packets onto the wire, it might as well context switch to that reply thread *after* point 6, because until after point 6, it can't marshal anything anyway.) So, I would like to consider a change such that 2-6 must happen in the same thread. It would make OTS and other services that have some implicit dependency on thread-specific data much easier to implement, and I don't think it would constrain ORB implementations. Resolution: Incorporate change close issue. Revised Text: The following paragraph be added to the end of section 21.3.10.2 "Additional Server-side Details" on page 21-17: If a POA and a servant locator are present, the order of their operations and interception points is: 1) ServerRequestInterceptor.receive_request_service_context 2) ServantLocator.preinvoke 3) ServerRequestInterceptor.receive_request 4) the operation 5) ServantLocator.postinvoke 6) ServerRequestInterceptor send_reply, send_exception, or send_other preinvoke, the operation, and postInvoke are required to execute in the same thread (see section 11.3.6 ServantLocator Interface on page 11-25). Since receive_request occurs within this chain, receive_request shall also execute in the same thread. postinvoke executes in the same thread as preinvoke in order for postinvoke to perform any necessary closure processing. Likewise, the sending interception points (send_reply, send_exception, and send_other) should also execute in the same thread. Adding this restriction changes a number of other statements in the spec as well. The following paragraphs in doc # ptc/2000-04-05 must also change: Page 21-14, first paragraph of section 21.3.9.2 "receive_request": This interception point allows an Interceptor to query request information after all the information, including operation parameters, are available. This interception point may or may not execute in the same thread as the target invocation. will change to: This interception point allows an Interceptor to query request information after all the information, including operation parameters, are available. This interception point shall execute in the same thread as the target invocation. The following sentence will be added to the end of the first paragraph in each of the sections: 21.3.9.3 "send_reply", 21.3.9.4 "send_exception", and 21.3.9.5 "send_other": This interception point shall execute in the same thread as the target invocation. Page 21-35, points 5 and 6 of section 21.4.4.5: 5. The ORB logically copies the RSC to the server-side TSC after the receive_request_service_context points are processed and before the servant manager is called. This TSC is within the context for both the invocation of the servant manager and the invocation of the target operation. The receive_request points may modify the RSC, but this no longer affects the TSC. 6. Control transfers to the server threads which may read and write this server-side TSC. will change to: 5. The ORB logically copies the RSC to the server-side TSC after the receive_request_service_context points are processed and before the servant manager is called. This TSC is within the context for the receive_request points, the invocation of the servant manager, and the invocation of the target operation. The receive_request points may modify the RSC, but this no longer affects the TSC. 6. The receive_request points are called. These points have access to the RSC - though modifying the RSC at this point has no affect on the TSC. Since these points execute in the same thread as the target operation invocation, these points may modify the server-side TSC. After the receive_request points are called, control transfers to the server threads which may also read and write this server-side TSC. Page 21-36, Figure 21-1 also needs changing. Either a two-way arrow must exist between the boxes for receive_request and Thread Scope PICurrent or the receive_request box is put within the Server Threads box. Ditto for the "Send Interception Points" box. Any preferences? Page 21-37, the last paragraph of section 21.4.4.6: Interceptors shall assume that each interception point logically runs in its own thread, with no context relationship between it and any other thread. While an ORB implementation may not actually behave in this manner, it is up to the ORB implementation to treat PICurrent as if it did. will change to: Interceptors shall assume that each client-side interception point logically runs in its own thread, with no context relationship between it and any other thread. While an ORB implementation may not actually behave in this manner, it is up to the ORB implementation to treat PICurrent as if it did. Interceptors shall assume that all server-side interception points except receive_request_service_context run in the same thread as the target operation invocation, thereby sharing thread context information. receive_request_service_context, like all client-side interception points, logically runs in its own thread, with no context relationship between it and any other thread. Actions taken: May 18, 2000: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== Date: Thu, 18 May 2000 10:58:00 +1000 (EST) From: Michi Henning Reply-To: interceptors-ftf@omg.org To: interceptors-ftf@omg.org cc: issues@omg.org Subject: Thread context switches Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: H*\!!L+f!!MA?!!gkFe9 Hi, the current draft permits receive_request_service_context, receive_request, the operation, and send_reply or send_exception to all run in different threads. This is rather inconvenient, especially for OTS, where I want to to talk to an XA interface from the interception points. The problem is that XA is sensitive to the calling thread and doesn't allow me to, for example, start something in one thread and finish it in another. Now, consider the following: - The POA spec already requires preinvoke, the operation, and postinvoke to run in the same thread. - The sequence of invocations if a servant locator is present for interceptors is: 1) receive_request_service_context 2) preinvoke 3) receive_request 4) operation 5) postinvoke 6) send_reply or send_exception Of these, 2, 4, and 5 must happen in the same thread. Now, what is the likelihood that an interceptor implementation will switch context after preinvoke and before receive_request, only to have to switch back to the original thread after preinvoke and before the operation? Essentially zero, I think. It's a lot harder and a lot less efficient to do that context switch than to not do it. In other words, I don't think we would lose anything if we required that 3 and 4 must run in the same thread. Similarly, an implementation isn't going to do a context switch after 4 (or 5) and before 6, because at point 6 I still must be able to modify the reply context. (If the ORB uses a separate thread to squirt reply packets onto the wire, it might as well context switch to that reply thread *after* point 6, because until after point 6, it can't marshal anything anyway.) So, I would like to consider a change such that 2-6 must happen in the same thread. It would make OTS and other services that have some implicit dependency on thread-specific data much easier to implement, and I don't think it would constrain ORB implementations. Opinions? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Reply-To: From: "Nick Sharman" To: Cc: Subject: RE: Thread context switches Date: Thu, 18 May 2000 10:43:11 +0100 Message-ID: <005001bfc0ad$7b317fe0$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: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: J`(!!Vc2e9pCWd9-e/e9 Michi, We would have no objections to such a requirement. As you say, there doesn't seem much point in zig-zagging between two threads, and XA interfacing is a good reason why it should be avoided. Regards Nick > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Thursday, May 18, 2000 1:58 AM > To: interceptors-ftf@omg.org > Cc: issues@omg.org > Subject: Thread context switches > > > Hi, > > the current draft permits receive_request_service_context, > receive_request, > the operation, and send_reply or send_exception to all run in different > threads. > > This is rather inconvenient, especially for OTS, where I want to > to talk to an XA interface from the interception points. The problem is > that XA is sensitive to the calling thread and doesn't allow me to, > for example, start something in one thread and finish it in another. > > Now, consider the following: > > - The POA spec already requires preinvoke, the operation, and > postinvoke to run in the same thread. > > - The sequence of invocations if a servant locator is present > for interceptors is: > > 1) receive_request_service_context > 2) preinvoke > 3) receive_request > 4) operation > 5) postinvoke > 6) send_reply or send_exception > > Of these, 2, 4, and 5 must happen in the same thread. > > Now, what is the likelihood that an interceptor implementation will > switch context after preinvoke and before receive_request, only to have > to switch back to the original thread after preinvoke and before the > operation? Essentially zero, I think. It's a lot harder and a lot less > efficient to do that context switch than to not do it. In other words, > I don't think we would lose anything if we required that 3 and 4 > must run in the same thread. > > Similarly, an implementation isn't going to do a context switch > after 4 (or 5) and before 6, because at point 6 I still must be able > to modify the reply context. (If the ORB uses a separate thread to squirt > reply packets onto the wire, it might as well context switch to that reply > thread *after* point 6, because until after point 6, it can't marshal > anything anyway.) > > So, I would like to consider a change such that 2-6 must happen in the > same thread. It would make OTS and other services that have some > implicit dependency on thread-specific data much easier to implement, > and I don't think it would constrain ORB implementations. > > Opinions? > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html > > From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA32934 for ; Thu, 18 May 2000 08:19:18 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id IAA27758 for ; Thu, 18 May 2000 08:28:34 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E3.0044883B ; Thu, 18 May 2000 08:28:33 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568E3.004486CF.00@d54mta04.raleigh.ibm.com> Date: Thu, 18 May 2000 08:28:27 -0400 Subject: Re: Thread context switches Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 0Q[!!OE4e9Ul9e952-e9 Michi, We could go along with this. I was trying to push this same idea early on, but my arguments weren't as clear as yours. I believe it was IONA that was most adamantly against this. Comments, Bob? Russell Butek butek@us.ibm.com Michi Henning on 05/17/2000 07:58:00 PM Please respond to interceptors-ftf@omg.org To: interceptors-ftf@omg.org cc: issues@omg.org Subject: Thread context switches Hi, the current draft permits receive_request_service_context, receive_request, the operation, and send_reply or send_exception to all run in different threads. This is rather inconvenient, especially for OTS, where I want to to talk to an XA interface from the interception points. The problem is that XA is sensitive to the calling thread and doesn't allow me to, for example, start something in one thread and finish it in another. Now, consider the following: - The POA spec already requires preinvoke, the operation, and postinvoke to run in the same thread. - The sequence of invocations if a servant locator is present for interceptors is: 1) receive_request_service_context 2) preinvoke 3) receive_request 4) operation 5) postinvoke 6) send_reply or send_exception Of these, 2, 4, and 5 must happen in the same thread. Now, what is the likelihood that an interceptor implementation will switch context after preinvoke and before receive_request, only to have to switch back to the original thread after preinvoke and before the operation? Essentially zero, I think. It's a lot harder and a lot less efficient to do that context switch than to not do it. In other words, I don't think we would lose anything if we required that 3 and 4 must run in the same thread. Similarly, an implementation isn't going to do a context switch after 4 (or 5) and before 6, because at point 6 I still must be able to modify the reply context. (If the ORB uses a separate thread to squirt reply packets onto the wire, it might as well context switch to that reply thread *after* point 6, because until after point 6, it can't marshal anything anyway.) So, I would like to consider a change such that 2-6 must happen in the same thread. It would make OTS and other services that have some implicit dependency on thread-specific data much easier to implement, and I don't think it would constrain ORB implementations. Opinions? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA26570 for ; Tue, 23 May 2000 16:55:14 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id RAA70276 for ; Tue, 23 May 2000 17:14:36 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E8.0074AF84 ; Tue, 23 May 2000 17:14:31 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568E8.007494F2.00@d54mta04.raleigh.ibm.com> Date: Tue, 23 May 2000 17:13:22 -0400 Subject: Issue 3619 Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: Icg!!OMe!!~](!!RjTd9 Michi, I'm trying to write up a proposal in line with your issue and I have one point I'd like to discuss. See my comments below... Russell Butek butek@us.ibm.com Michi Henning on 05/17/2000 07:58:00 PM > > the current draft permits receive_request_service_context, receive_request, > the operation, and send_reply or send_exception to all run in different > threads. > > This is rather inconvenient, especially for OTS, where I want to > to talk to an XA interface from the interception points. The problem is > that XA is sensitive to the calling thread and doesn't allow me to, > for example, start something in one thread and finish it in another. > > Now, consider the following: > > - The POA spec already requires preinvoke, the operation, and > postinvoke to run in the same thread. > > - The sequence of invocations if a servant locator is present > for interceptors is: > > 1) receive_request_service_context > 2) preinvoke > 3) receive_request > 4) operation > 5) postinvoke > 6) send_reply or send_exception > > Of these, 2, 4, and 5 must happen in the same thread. > > Now, what is the likelihood that an interceptor implementation will > switch context after preinvoke and before receive_request, only to have > to switch back to the original thread after preinvoke and before the > operation? Essentially zero, I think. It's a lot harder and a lot less > efficient to do that context switch than to not do it. In other words, > I don't think we would lose anything if we required that 3 and 4 > must run in the same thread. > > Similarly, an implementation isn't going to do a context switch > after 4 (or 5) and before 6, because at point 6 I still must be able > to modify the reply context. (If the ORB uses a separate thread to squirt > reply packets onto the wire, it might as well context switch to that reply > thread *after* point 6, because until after point 6, it can't marshal > anything anyway.) Actually, stream-based skeletons WILL marshal their data before point 6 is reached. This is the whole reason for allowing NO_RESOURCES to be raised on a call ServerRequestInfo.arguments, etc. That particular data isn't available if the skeleton streamed the return values. (And in GIOP 1.2 the data must start on an 8-byte boundary, so there's no worry about proper padding between message header and message data.) So, given this, is there another argument for putting 6 in the same thread as 2-5, other than that it might make ORB implementations simpler? I don't have a big problem myself with putting 6 in the same thread (other than that the resolution involves more changes), but I don't see a good justification. > > So, I would like to consider a change such that 2-6 must happen in >the > same thread. It would make OTS and other services that have some > implicit dependency on thread-specific data much easier to >implement, > and I don't think it would constrain ORB implementations. > > Opinions? > Date: Wed, 24 May 2000 09:55:13 +1000 (EST) From: Michi Henning To: butek@us.ibm.com cc: interceptors-ftf@omg.org Subject: Re: Issue 3619 In-Reply-To: <852568E8.007494F2.00@d54mta04.raleigh.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ^*[d9X"T!!?a""!>%j!! On Tue, 23 May 2000 butek@us.ibm.com wrote: > Actually, stream-based skeletons WILL marshal their data before point 6 is > reached. This is the whole reason for allowing NO_RESOURCES to be raised > on a call ServerRequestInfo.arguments, etc. Hmmm... If stream-based skeletons marshal data at that point, how can the final interception point still modify the data? Doesn't the spec say that this must be possible? > That particular data isn't > available if the skeleton streamed the return values. (And in GIOP > 1.2 the > data must start on an 8-byte boundary, so there's no worry about > proper > padding between message header and message data.) So, given this, > is there > another argument for putting 6 in the same thread as 2-5, other than > that > it might make ORB implementations simpler? > > I don't have a big problem myself with putting 6 in the same thread > (other > than that the resolution involves more changes), but I don't see a > good > justification. The point is that, for things like XA integration for OTS, the call to XA_close (or XA_end, forget which) must happen in the same thread as the call to XA_begin (or XA_open or XA_start, whatever...) So, if the final interception point doesn't run in the same thread as receive_request, that is no longer possible, and there is no hook where I could do the XA calls. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Tue, 23 May 2000 18:19:50 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: butek@us.ibm.com, interceptors-ftf@omg.org Subject: Re: Issue 3619 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: W5*e9n!Vd94'Q!!dHJ!! If by "modify the data" you mean change the marshaled arguments the spec does not allow that. All the spec says is that you can look at the data IF the language mapping supports it (and the java stream-based stubs/skels do not support this). Cheers, harold Michi Henning wrote: > > On Tue, 23 May 2000 butek@us.ibm.com wrote: > > > Actually, stream-based skeletons WILL marshal their data before point 6 is > > reached. This is the whole reason for allowing NO_RESOURCES to be raised > > on a call ServerRequestInfo.arguments, etc. > > Hmmm... If stream-based skeletons marshal data at that point, how can > the final interception point still modify the data? Doesn't the spec > say that this must be possible? From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA56960 for ; Wed, 24 May 2000 09:39:16 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id JAA60676 for ; Wed, 24 May 2000 09:48:35 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E9.004BDB3F ; Wed, 24 May 2000 09:48:33 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568E9.004BD5D5.00@d54mta04.raleigh.ibm.com> Date: Wed, 24 May 2000 09:48:16 -0400 Subject: Re: Issue 3619 Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 2\Yd9Tncd9k`[d9Q#Td9 Michi Henning on 05/23/2000 06:55:13 PM > > On Tue, 23 May 2000 butek@us.ibm.com wrote: > > > Actually, stream-based skeletons WILL marshal their data before point 6 is > > reached. This is the whole reason for allowing NO_RESOURCES to be raised > > on a call ServerRequestInfo.arguments, etc. > > Hmmm... If stream-based skeletons marshal data at that point, how can > the final interception point still modify the data? Doesn't the spec > say that this must be possible? > Sorry, let me clarify that. Stream-based skeletons marshal only the reply data before point 6. The reply header cannot be marshaled until point 6 completes, and the data is just tacked onto the end of the header at that time. > > That particular data isn't > > available if the skeleton streamed the return values. (And in > > GIOP 1.2 the > > data must start on an 8-byte boundary, so there's no worry about > > proper > > padding between message header and message data.) So, given this, > > is there > > another argument for putting 6 in the same thread as 2-5, other > > than that > > it might make ORB implementations simpler? > > > > I don't have a big problem myself with putting 6 in the same > > thread (other > > than that the resolution involves more changes), but I don't see a > > good > > justification. > > The point is that, for things like XA integration for OTS, the call > > to > XA_close (or XA_end, forget which) must happen in the same thread > as the call to XA_begin (or XA_open or XA_start, whatever...) > So, if the final interception point doesn't run in the same thread > > as > receive_request, that is no longer possible, and there is no hook > > where > I could do the XA calls. > Good enough for me. Look for my proposal sometime in the next few hours... Russell Butek butek@us.ibm.com Date: Wed, 24 May 2000 10:04:03 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: butek@us.ibm.com CC: interceptors-ftf@omg.org, Matthew Mihic , Eric Newcomer Subject: Re: Issue 3619 References: <852568E9.004BD5D5.00@d54mta04.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: $ePd944W!!k0*e9fAE!! butek@us.ibm.com wrote: > Sorry, let me clarify that. Stream-based skeletons marshal only the reply > data before point 6. The reply header cannot be marshaled until point 6 > completes, and the data is just tacked onto the end of the header at that > time. I simply haven't had time to follow this discussion, but you are making some very significant assumptions here they may not be warranted. The whole point of fragmentation in GIOP is to allow the ORB to stream out the messages as they are marshaled. Requiring the ORB to buffer the marshaled parameters in memory before marshaling the header is not likely to be acceptable to most ORB implementors. > > > > That particular data isn't > > > available if the skeleton streamed the return values. (And in GIOP 1.2 > the > > > data must start on an 8-byte boundary, so there's no worry about proper > > > padding between message header and message data.) So, given this, is > there > > > another argument for putting 6 in the same thread as 2-5, other than > that > > > it might make ORB implementations simpler? > > > > > > I don't have a big problem myself with putting 6 in the same thread > (other > > > than that the resolution involves more changes), but I don't see a good > > > justification. > > > > The point is that, for things like XA integration for OTS, the call to > > XA_close (or XA_end, forget which) must happen in the same thread > > as the call to XA_begin (or XA_open or XA_start, whatever...) > > So, if the final interception point doesn't run in the same thread as > > receive_request, that is no longer possible, and there is no hook where > > I could do the XA calls. > > > > Good enough for me. Look for my proposal sometime in the next few hours... Again, I haven't had a time to follow this discussion, and it seems Matt Mihic had fallen off the email list sometime back, so I guess he hasn't been covering it either. IONA does not, as far as I know, support the addition of a constraint that significant sets of the intercept points be required to run in the same thread as each other and the servant. I'm hoping Matt will be able to check and see if the proposal really is a problem for us, and if it isn't, we probably won't oppose it, but I'm not confident that this change is something we would find acceptable. I'm wondering if other approaches to XA integration have been considered. My understanding was that this has not been standardized in the OTS specification, so maybe a better solution would be to add operations to the OTS current that cause the thread's transaction to become available to XA and to decouple XA from the transaction. Applications (or containers) would need to make these calls before and after using XA from the servant. But this would maintain the decoupling of CORBA from system-provided thread-specific-data mechanisms, which probably is a good thing. -Bob > > Russell Butek > butek@us.ibm.com Date: Wed, 24 May 2000 11:55:48 -0230 From: Matthew Newhook To: Bob Kukura Cc: butek@us.ibm.com, interceptors-ftf@omg.org, Matthew Mihic , Eric Newcomer Subject: Re: Issue 3619 Message-ID: <20000524115548.A16854@ooc.com> References: <852568E9.004BD5D5.00@d54mta04.raleigh.ibm.com> <392BE153.4A6CFE8C@iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <392BE153.4A6CFE8C@iona.com> Content-Type: text/plain; charset=us-ascii X-UIDL: OCI!!Z@Oe9M$;!!je$!! Hi Bob, On Wed, May 24, 2000 at 10:04:03AM -0400, Bob Kukura wrote: > Again, I haven't had a time to follow this discussion, and it seems Matt > Mihic had fallen off the email list sometime back, so I guess he hasn't > been covering it either. IONA does not, as far as I know, support the > addition of a constraint that significant sets of the intercept points > be required to run in the same thread as each other and the servant. > I'm hoping Matt will be able to check and see if the proposal really is > a problem for us, and if it isn't, we probably won't oppose it, but I'm > not confident that this change is something we would find acceptable. Because of the thread constraints that ServantLocators already put on ORB implementors (namely that preinvoke and postinvoke have to run in the same thread as the request) it seems to me that the the ORB would actually have to go out of its way to run most of the interception points in a thread other than the request thread. > -Bob 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 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA40394; Wed, 24 May 2000 10:33:03 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id KAA75222; Wed, 24 May 2000 10:45:27 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E9.005110A8 ; Wed, 24 May 2000 10:45:26 -0400 X-Lotus-FromDomain: IBMUS To: Bob Kukura cc: interceptors-ftf@omg.org, Matthew Mihic , Eric Newcomer Message-ID: <852568E9.00510D92.00@d54mta04.raleigh.ibm.com> Date: Wed, 24 May 2000 10:45:16 -0400 Subject: Re: Issue 3619 Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: mjGe9mNm!!5W/!!`2Ce9 Bob Kukura on 05/24/2000 09:04:03 AM > > butek@us.ibm.com wrote: > > > Sorry, let me clarify that. Stream-based skeletons marshal only the reply > > data before point 6. The reply header cannot be marshaled until point 6 > > completes, and the data is just tacked onto the end of the header at that > > time. > > I simply haven't had time to follow this discussion, but you are making > some very significant assumptions here they may not be warranted. The > whole point of fragmentation in GIOP is to allow the ORB to stream out > the messages as they are marshaled. Requiring the ORB to buffer the > marshaled parameters in memory before marshaling the header is not > likely to be acceptable to most ORB implementors. > Yeah, you're right. I hate fragments and I tend not to think about them. In any case, this was a tangential discussion to the main topic and I don't think it has any bearing one way or the other. I'd like to hear your or Matt's arguments against the main topic, though. In his initial note, Michi presented a fairly good argument FOR putting all these points into the same thread. If we CANNOT do that, there are some pretty significant problems. Russell Butek butek@us.ibm.com From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA10108 for ; Wed, 24 May 2000 12:58:57 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id NAA39908 for ; Wed, 24 May 2000 13:11:25 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E9.005E6DAE ; Wed, 24 May 2000 13:11:24 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568E9.005DD459.00@d54mta04.raleigh.ibm.com> Date: Wed, 24 May 2000 13:04:50 -0400 Subject: Issue 3619 proposal Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: /=0!!*[Oe9gk*e93O"e9 Somewhere we have to add a paragraph explaining what the issue says. I propose that the following paragraph be added to the end of section 21.3.10.2 "Additional Server-side Details" on page 21-17: If a POA and a servant locator are present, the order of their operations and interception points is: 1) ServerRequestInterceptor.receive_request_service_context 2) ServantLocator.preinvoke 3) ServerRequestInterceptor.receive_request 4) the operation 5) ServantLocator.postinvoke 6) ServerRequestInterceptor send_reply, send_exception, or send_other preinvoke, the operation, and postInvoke are required to execute in the same thread (see section 11.3.6 ServantLocator Interface on page 11-25). Since receive_request occurs within this chain, receive_request shall also execute in the same thread. postinvoke executes in the same thread as preinvoke in order for postinvoke to perform any necessary closure processing. Likewise, the sending interception points (send_reply, send_exception, and send_other) should also execute in the same thread. Adding this restriction changes a number of other statements in the spec as well. The following paragraphs in doc # ptc/2000-04-05 must also change: Page 21-14, first paragraph of section 21.3.9.2 "receive_request": This interception point allows an Interceptor to query request information after all the information, including operation parameters, are available. This interception point may or may not execute in the same thread as the target invocation. will change to: This interception point allows an Interceptor to query request information after all the information, including operation parameters, are available. This interception point shall execute in the same thread as the target invocation. The following sentence will be added to the end of the first paragraph in each of the sections: 21.3.9.3 "send_reply", 21.3.9.4 "send_exception", and 21.3.9.5 "send_other": This interception point shall execute in the same thread as the target invocation. Page 21-35, points 5 and 6 of section 21.4.4.5: 5. The ORB logically copies the RSC to the server-side TSC after the receive_request_service_context points are processed and before the servant manager is called. This TSC is within the context for both the invocation of the servant manager and the invocation of the target operation. The receive_request points may modify the RSC, but this no longer affects the TSC. 6. Control transfers to the server threads which may read and write this server-side TSC. will change to: 5. The ORB logically copies the RSC to the server-side TSC after the receive_request_service_context points are processed and before the servant manager is called. This TSC is within the context for the receive_request points, the invocation of the servant manager, and the invocation of the target operation. The receive_request points may modify the RSC, but this no longer affects the TSC. 6. The receive_request points are called. These points have access to the RSC - though modifying the RSC at this point has no affect on the TSC. Since these points execute in the same thread as the target operation invocation, these points may modify the server-side TSC. After the receive_request points are called, control transfers to the server threads which may also read and write this server-side TSC. Page 21-36, Figure 21-1 also needs changing. Either a two-way arrow must exist between the boxes for receive_request and Thread Scope PICurrent or the receive_request box is put within the Server Threads box. Ditto for the "Send Interception Points" box. Any preferences? Page 21-37, the last paragraph of section 21.4.4.6: Interceptors shall assume that each interception point logically runs in its own thread, with no context relationship between it and any other thread. While an ORB implementation may not actually behave in this manner, it is up to the ORB implementation to treat PICurrent as if it did. will change to: Interceptors shall assume that each client-side interception point logically runs in its own thread, with no context relationship between it and any other thread. While an ORB implementation may not actually behave in this manner, it is up to the ORB implementation to treat PICurrent as if it did. Interceptors shall assume that all server-side interception points except receive_request_service_context run in the same thread as the target operation invocation, thereby sharing thread context information. receive_request_service_context, like all client-side interception points, logically runs in its own thread, with no context relationship between it and any other thread. Russell Butek butek@us.ibm.com From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Issue 3619 Date: Wed, 24 May 2000 13:23:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ;Q0e9Ee+e9G!De9Og*e9 > From: Bob Kukura [mailto:kukura@iona.com] > I simply haven't had time to follow this discussion, but you > are making > some very significant assumptions here they may not be warranted. > The > whole point of fragmentation in GIOP is to allow the ORB to stream > out > the messages as they are marshaled. Requiring the ORB to buffer the > marshaled parameters in memory before marshaling the header is not > likely to be acceptable to most ORB implementors. I agree with Bob on this. Marshalling the reply on the fly implies not only what java is apparently doing, but also that parts of the reply header may be gone even before the first argument is marshalled. Paul From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Issue 3619 proposal Date: Wed, 24 May 2000 18:12:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: \oj!!ZnN!!FYP!!73Ne9 I haven't studied this carefully yet, but the following problem came to mind immediately: The servant locator can be an orb mediated object. There are a couple of consequences when this is the case: - what did we decide about interceptors for collocated calls? those can be interleaved with the ones for the first call. - an orb mediated servant locator can make it impossible for the servant locator to run in the same thread as the call on the located servant. (They can be in different POAs, with incompatible threading policies.) Paul > -----Original Message----- > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Sent: Wednesday, May 24, 2000 1:05 PM > To: interceptors-ftf@omg.org > Subject: Issue 3619 proposal > > > > > Somewhere we have to add a paragraph explaining what the > issue says. I > propose that the following paragraph be added to the end of section > 21.3.10.2 "Additional Server-side Details" on page 21-17: > > If a POA and a servant locator are present, the order of their > operations and > interception points is: > 1) ServerRequestInterceptor.receive_request_service_context > 2) ServantLocator.preinvoke > 3) ServerRequestInterceptor.receive_request > 4) the operation > 5) ServantLocator.postinvoke > 6) ServerRequestInterceptor send_reply, send_exception, or > send_other > > preinvoke, the operation, and postInvoke are required to > execute in > the same > thread (see section 11.3.6 ServantLocator Interface on > page 11-25). > Since > receive_request occurs within this chain, > receive_request shall also > execute > in the same thread. > > postinvoke executes in the same thread as preinvoke in order for > postinvoke > to perform any necessary closure processing. Likewise, > the sending > interception points (send_reply, send_exception, and send_other) > should > also execute in the same thread. > > > Adding this restriction changes a number of other statements > in the spec as > well. The following paragraphs in doc # ptc/2000-04-05 must > also change: > > Page 21-14, first paragraph of section 21.3.9.2 "receive_request": > > This interception point allows an Interceptor to query > request information > after all the > information, including operation parameters, are available. This > interception point may > or may not execute in the same thread as the target invocation. > > will change to: > > This interception point allows an Interceptor to query > request information > after all the > information, including operation parameters, are available. This > interception point > shall execute in the same thread as the target invocation. > > > The following sentence will be added to the end of the first > paragraph in > each of the sections: 21.3.9.3 "send_reply", 21.3.9.4 > "send_exception", > and 21.3.9.5 "send_other": > > This interception point shall execute in the same thread as the target > invocation. > > > Page 21-35, points 5 and 6 of section 21.4.4.5: > > 5. The ORB logically copies the RSC to the server-side TSC after the > receive_request_service_context points are processed and > before the servant > manager is called. This TSC is within the context for both > the invocation > of the > servant manager and the invocation of the target operation. The > receive_request > points may modify the RSC, but this no longer affects the TSC. > > 6. Control transfers to the server threads which may read and > write this > server-side > TSC. > > will change to: > > 5. The ORB logically copies the RSC to the server-side TSC after the > receive_request_service_context points are processed and > before the servant > manager is called. This TSC is within the context for the > receive_request > points, > the invocation of the servant manager, and the invocation of > the target > operation. > The receive_request points may modify the RSC, but this no > longer affects > the > TSC. > > 6. The receive_request points are called. These points have > access to the > RSC - > though modifying the RSC at this point has no affect on the > TSC. Since > these > points execute in the same thread as the target operation > invocation, these > points > may modify the server-side TSC. After the receive_request points are > called, > control transfers to the server threads which may also read > and write this > server-side TSC. > > > Page 21-36, Figure 21-1 also needs changing. Either a > two-way arrow must > exist between the boxes for receive_request and Thread Scope > PICurrent or > the receive_request box is put within the Server Threads box. > Ditto for > the "Send Interception Points" box. Any preferences? > > > Page 21-37, the last paragraph of section 21.4.4.6: > > Interceptors shall assume that each interception point > logically runs in > its own thread, > with no context relationship between it and any other thread. > While an ORB > implementation may not actually behave in this manner, it is > up to the ORB > implementation to treat PICurrent as if it did. > > will change to: > > Interceptors shall assume that each client-side interception point > logically > runs in its own thread, with no context relationship between > it and any > other > thread. While an ORB implementation may not actually behave > in this manner, > > it is up to the ORB implementation to treat PICurrent as if it did. > > Interceptors shall assume that all server-side interception > points except > receive_request_service_context run in the same thread as the target > operation invocation, thereby sharing thread context information. > receive_request_service_context, like all client-side > interception points, > logically runs in its own thread, with no context > relationship between it > and > any other thread. > > > Russell Butek > butek@us.ibm.com > > Date: Thu, 25 May 2000 10:57:12 +1000 (EST) From: Michi Henning To: butek@us.ibm.com cc: Bob Kukura , interceptors-ftf@omg.org, Matthew Mihic , Eric Newcomer Subject: Re: Issue 3619 In-Reply-To: <852568E9.00510D92.00@d54mta04.raleigh.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: H6_!!llYd9H[6e9-Eld9 On Wed, 24 May 2000 butek@us.ibm.com wrote: > Yeah, you're right. I hate fragments and I tend not to think about them. > In any case, this was a tangential discussion to the main topic and I don't > think it has any bearing one way or the other. > > I'd like to hear your or Matt's arguments against the main topic, though. > In his initial note, Michi presented a fairly good argument FOR putting all > these points into the same thread. If we CANNOT do that, there are some > pretty significant problems. The way I see it, marshaling of fragments can't start until at least postinvoke has finished (because postinvoke may raise an exception). So, I see marshaling of fragments as an advantage only if we you use the AOM when there is no postinvoke call. But then, all of the operation reply is held completely in buffers until the operation returns control to the skeleton anyway, so there seems little point in fragmenting anything at that point, no? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 24 May 2000 20:59:28 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: butek@us.ibm.com, interceptors-ftf@omg.org, Matthew Mihic , Eric Newcomer Subject: Re: Issue 3619 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: K>2e98b*e9;9!!!\TC!! I've never had any reason to believe that an exception raised in postinvoke would necessarily be returned to the client. -Bob Michi Henning wrote: > > On Wed, 24 May 2000 butek@us.ibm.com wrote: > > > Yeah, you're right. I hate fragments and I tend not to think about them. > > In any case, this was a tangential discussion to the main topic and I don't > > think it has any bearing one way or the other. > > > > I'd like to hear your or Matt's arguments against the main topic, though. > > In his initial note, Michi presented a fairly good argument FOR putting all > > these points into the same thread. If we CANNOT do that, there are some > > pretty significant problems. > > The way I see it, marshaling of fragments can't start until at least > postinvoke has finished (because postinvoke may raise an exception). > So, I see marshaling of fragments as an advantage only if we you use > the AOM when there is no postinvoke call. But then, all of the operation > reply is held completely in buffers until the operation returns control > to the skeleton anyway, so there seems little point in fragmenting anything > at that point, no? > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 25 May 2000 11:09:17 +1000 (EST) From: Michi Henning To: Bob Kukura cc: butek@us.ibm.com, interceptors-ftf@omg.org, Matthew Mihic , Eric Newcomer Subject: Re: Issue 3619 In-Reply-To: <392C7AF0.2ACC8DB4@iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Z3T!!/i4e9/V/e9pZ(e9 On Wed, 24 May 2000, Bob Kukura wrote: > I've never had any reason to believe that an exception raised in > postinvoke would necessarily be returned to the client. Page 11-27: The postinvoke operation is considered to be part of a request on an object. That is, the request is not complete until postinvoke finishes. If the method finishes normally but postinvoke raises a system exception, the method's normal return is overridden; the request completes with the exception. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 25 May 2000 11:13:43 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interceptors-ftf@omg.org Subject: RE: Issue 3619 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BEC0@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: o I agree with Bob on this. Marshalling the reply on the fly implies not only > what java is apparently doing, but also that parts of the reply header may > be gone even before the first argument is marshalled. If a servant locator is used, that is fundamentally impossible, given the current words in the spec, because postinvoke() may raise an exception and that exception must be given to the client instead of the operation result. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 24 May 2000 21:44:28 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: butek@us.ibm.com, interceptors-ftf@omg.org, Matthew Mihic , Eric Newcomer Subject: Re: Issue 3619 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: %P%e9hK>!!-ff!!`85!! I must have somehow got confused about this. Matt Mihic cleared it up for me. In our C++ ORB, we do not marshal or send the reply until after postinvoke has returned. We do stream the reply as we marshal it, using fragments if appropriate. Our Java ORB's stream based portable skeletons may be another matter, and I don't make any claim to understand exactly how those work. I apologize for the confusion. -Bob Michi Henning wrote: > > On Wed, 24 May 2000, Bob Kukura wrote: > > > I've never had any reason to believe that an exception raised in > > postinvoke would necessarily be returned to the client. > > Page 11-27: > > The postinvoke operation is considered to be part of a request > on an object. That is, the request is not complete until postinvoke > finishes. If the method finishes normally but postinvoke raises > a system exception, the method's normal return is overridden; > the request completes with the exception. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 25 May 2000 11:59:37 +1000 (EST) From: Michi Henning To: Bob Kukura cc: butek@us.ibm.com, interceptors-ftf@omg.org, Matthew Mihic , Eric Newcomer Subject: Re: Issue 3619 In-Reply-To: <392C857C.A658E4AA@iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ,3[d9`ID!!N<-!!3T"e9 On Wed, 24 May 2000, Bob Kukura wrote: > I must have somehow got confused about this. Matt Mihic cleared it up > for me. In our C++ ORB, we do not marshal or send the reply until after > postinvoke has returned. We do stream the reply as we marshal it, using > fragments if appropriate. Our Java ORB's stream based portable > skeletons may be another matter, and I don't make any claim to > understand exactly how those work. I apologize for the confusion. Is it a big deal then to call the interceptor outgoing interception point in the same thread? The way I see it, the cost of keeping the same thread is less than doing a context switch. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 25 May 2000 12:11:18 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interceptors-ftf@omg.org Subject: RE: Issue 3619 proposal In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BEC9@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 57N!!a`De9,Mnd9]3 I haven't studied this carefully yet, but the following problem came to mind > immediately: > > The servant locator can be an orb mediated object. How can a servant locator be ORB-mediated? When I call set_servant_manager, I do it on a POA, and that POA has a POA manager. When I transition the POA manager to the inactive state, calls that are currently ongoing are supposed to complete. However, if the servant locator is ORB-mediated, the calls to postinvoke() can't happen because, if they are ORB-mediated, the POA manager is in the inactive state already because there are no invocations on the servant locator that are ongoing and should finish first... To me, it still seems that the idea of servant managers being ORB-mediated is wrong. Servant managers are simple helper objects for a POA, not fully-fledged CORBA objects. (They are locality constrained, at any rate.) > consequences when this is the case: > > - what did we decide about interceptors for collocated calls? > those can be interleaved with the ones for the first call. Sorry, I don't know what you mean. Can you explain? > - an orb mediated servant locator can make it impossible for the servant > locator to run in the same thread as the call on the located servant. > (They can be in different POAs, with incompatible threading policies.) According to the spec, that would appear to be illegal. For one, the spec requires that preinvoke, the operation, and postinvoke must run in the same thread. Second, if a servant locator is called on a POA to locate a servant, that servant must be activated on that same POA (otherwise, the servant locator wouldn't have been called for that POA). Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Reply-To: From: "Nick Sharman" To: Subject: RE: Issue 3619 proposal Date: Thu, 25 May 2000 09:42:48 +0100 Message-ID: <009601bfc625$34326230$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: d`Td9'@j!!`%k!!/NJd9 > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Thursday, May 25, 2000 3:11 AM > To: Paul Kyzivat > Cc: interceptors-ftf@omg.org > Subject: RE: Issue 3619 proposal > > > On Wed, 24 May 2000, Paul Kyzivat wrote: > > > I haven't studied this carefully yet, but the following problem > came to mind > > immediately: > > > > The servant locator can be an orb mediated object. > > How can a servant locator be ORB-mediated? > The words in ptc/00-03-02 (CORBA 2.4 draft) and ptc/00-04-05 (Interceptors FTF draft) are: 11.3.4.2 Locality Constraints A ServantManager object must be local to the process containing the POA objects it is registered with. Unfortunately, it doesn't say it's "locally constrained" (even though none of the standard operations are usable remotely, since they take "native" parameters). It's possible a user-defined interface derived from one of the standard ServantManager interfaces could have some operation, callable from afar, that would affect its behavior on the next standard operation invocation. Has anyone ever done such a thing? It would probably be better design to have a separate ServantManagerManager (!) interface that itself calls the actual ServantManager object(s). In any case, the CCM FTF ride to the rescue - although 11.3.4.2 in their ptc/99-10-03 has the same wording, the IDL in 11.4 has the magic keyword "local" on ServantManager and its derived interfaces and also on AdapterActivator. So I think we should assume that 11.3.4.2 meant "locally constrained" (and so not ORB- or POA-mediated) all along - do we need a Core issue to nail this down until 3.0? Regards Nick Reply-To: From: "Nick Sharman" To: Subject: RE: Issue 3619 proposal Date: Thu, 25 May 2000 13:03:35 +0100 Message-ID: <00a401bfc641$40c528e0$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <20000525090155.D23799@ooc.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: >, -----Original Message----- > From: Matthew Newhook [mailto:matthew@ooc.com] > Sent: Thursday, May 25, 2000 12:32 PM > To: Nick Sharman > Cc: interceptors-ftf@omg.org > Subject: Re: Issue 3619 proposal > > > Hi, > > On Thu, May 25, 2000 at 09:42:48AM +0100, Nick Sharman wrote: > >[...] > > So I think we should assume that 11.3.4.2 meant "locally > constrained" (and > > so not ORB- or POA-mediated) all along - do we need a Core issue to nail > > this down until 3.0? > > As much as I hate the fact that servant managers are ORB mediated, that > would be an invalid assumption. For one thing prior to local interfaces > there are no standard way to have a locality constrained object that the > end-user could implement. > > > Regards > > Nick > > 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: Issue 3619 Date: Thu, 25 May 2000 08:42:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: %_kd9+?-!!8:4!!TRm!! > From: Michi Henning [mailto:michi@ooc.com.au] > > I agree with Bob on this. Marshalling the reply on the fly > implies not only > > what java is apparently doing, but also that parts of the > reply header may > > be gone even before the first argument is marshalled. > > If a servant locator is used, that is fundamentally impossible, given > the current words in the spec, because postinvoke() may raise > an exception > and that exception must be given to the client instead of the > operation result. And Michi wrote in another message: > The way I see it, marshaling of fragments can't start until at least > postinvoke has finished (because postinvoke may raise an exception). I didn't mean to imply that marshalling would begin prior to postinvoke - I was only responding to the implication that stream based marshalling would result in a marshalled stream all present in memory, and complete before the header is marshalled. > So, I see marshaling of fragments as an advantage only if we you use > the AOM when there is no postinvoke call. But then, all of > the operation > reply is held completely in buffers until the operation > returns control > to the skeleton anyway, so there seems little point in > fragmenting anything at that point, no? No. If you have a call with some very big arguments, it is unavoidable that those arguments must be in memory, in their language binding representation, once. What fragmentation does is eliminate the need for another full copy of those arguments to simultaneously be in memory a second time, in marshalled form. Instead, there is a bounded additional cost - the size of one fragment. This is unrelated to the activation model. All you need to do is unmarshal the request header to get the key, then locate the POA and servant according to the appropriate policies (including possibly running a servant locator), and then unmarshal the arguments. >From this discussion, it is clear that there are a lot of ways to skin the marshalling cat, and among us we have probably used most of them. Paul Date: Thu, 25 May 2000 20:08:46 +1000 (EST) From: Michi Henning To: Nick Sharman cc: interceptors-ftf@omg.org Subject: RE: Issue 3619 proposal In-Reply-To: <009601bfc625$34326230$5610a8c0@thumper.uk.peerlogic.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ,8^!!&SSd9W1b!!MQp!! On Thu, 25 May 2000, Nick Sharman wrote: > So I think we should assume that 11.3.4.2 meant "locally constrained" (and > so not ORB- or POA-mediated) all along - do we need a Core issue to nail > this down until 3.0? Well, I guess we can't get it into 2.4 anymore, so it will have to wait until 3.0. But we shouldn't make decisions that are based on the assumption that these things are ORB-mediated. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 25 May 2000 09:01:55 -0230 From: Matthew Newhook To: Nick Sharman Cc: interceptors-ftf@omg.org Subject: Re: Issue 3619 proposal Message-ID: <20000525090155.D23799@ooc.com> References: <009601bfc625$34326230$5610a8c0@thumper.uk.peerlogic.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <009601bfc625$34326230$5610a8c0@thumper.uk.peerlogic.com> Content-Type: text/plain; charset=us-ascii X-UIDL: e'W!!mTXd9]+Ee95a!e9 Hi, On Thu, May 25, 2000 at 09:42:48AM +0100, Nick Sharman wrote: >[...] > So I think we should assume that 11.3.4.2 meant "locally constrained" (and > so not ORB- or POA-mediated) all along - do we need a Core issue to nail > this down until 3.0? As much as I hate the fact that servant managers are ORB mediated, that would be an invalid assumption. For one thing prior to local interfaces there are no standard way to have a locality constrained object that the end-user could implement. > Regards > Nick 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: Issue 3619 proposal Date: Thu, 25 May 2000 11:50:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: m'D!!N90e9 !!_RYd9 > From: Nick Sharman [mailto:nick.sharman@peerlogic.com] > The words in ptc/00-03-02 (CORBA 2.4 draft) and ptc/00-04-05 > (Interceptors > FTF draft) are: > > 11.3.4.2 Locality Constraints > > A ServantManager object must be local to the process > containing the POA > objects it is registered with. > > Unfortunately, it doesn't say it's "locally constrained" > (even though none > of the standard operations are usable remotely, since they > take "native" > parameters). > > It's possible a user-defined interface derived from one of > the standard > ServantManager interfaces could have some operation, callable > from afar, > that would affect its behavior on the next standard operation > invocation. > Has anyone ever done such a thing? It would probably be > better design to > have a separate ServantManagerManager (!) interface that > itself calls the > actual ServantManager object(s). > > In any case, the CCM FTF ride to the rescue - although > 11.3.4.2 in their > ptc/99-10-03 has the same wording, the IDL in 11.4 has the > magic keyword > "local" on ServantManager and its derived interfaces and also on > AdapterActivator. > > So I think we should assume that 11.3.4.2 meant "locally > constrained" (and > so not ORB- or POA-mediated) all along - do we need a Core > issue to nail > this down until 3.0? I must say that I am confused about the current status of this - must not have been keeping up with my reading. - has a change been approved (by an rtf at least) that permits servant managers to be local (non-orb-mediated)? - does it forbid servant managers that *are* orb-mediated? - in what corba version is it expected to take effect? Paul From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Issue 3619 proposal Date: Thu, 25 May 2000 10:14:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: U' From: Michi Henning [mailto:michi@ooc.com.au] > > I haven't studied this carefully yet, but the following > problem came to mind > > immediately: > > > > The servant locator can be an orb mediated object. > > How can a servant locator be ORB-mediated? Well, the spec says that servant managers are real (but locally constrained) objects. We have (or are in the process of) changed to to permit (but not require) the use of local objects. We have also agreed that collocated calls to real objects are orb mediated. So, if I use a real, collocated, object as a servant locator then calls to it will be orb mediated. > > When I call set_servant_manager, I do it on a POA, and that POA has > a > POA manager. When I transition the POA manager to the inactive > state, > calls that are currently ongoing are supposed to complete. However, > if > the servant locator is ORB-mediated, the calls to > postinvoke() can't happen > because, if they are ORB-mediated, the POA manager is in the > inactive > state already because there are no invocations on the servant > locator > that are ongoing and should finish first... I am not sure I follow the point you are trying to make, or your assumptions. But keep in mind that the POA the servant locator is installed in, and the POA the servant locator is activated in may not (must not) be the same. And while those two POAs could share a POAManager, they need not. So the state of those two POAs may be independent. Of course this can lead to some odd usage scenarios. (E.g., If you put the POAManager for the servant locator's POA into holding state, then invocations on objects in another POA that uses that servant locator will stall.) In a case like this you may have to be very careful in what order POAManagers are manipulated, and in what order POAs are destroyed. But there certainly ways to arrange this that do work. > > To me, it still seems that the idea of servant managers being > ORB-mediated > is wrong. Servant managers are simple helper objects for a POA, not > fully-fledged CORBA objects. (They are locality constrained, > at any rate.) I am not going to argue with you on this one, except that historically it was specified to use orb mediated objects, and that usage is still valid. We should not be designing enhancements that break conforming programs. If we become convinced that we can no longer support orb-mediated servant managers, then we need to change the spec to forbid them. And since this is an incompatible change, it will be a hard one to make. I know it would break many existing programs. > > > consequences when this is the case: > > > > - what did we decide about interceptors for collocated calls? > > those can be interleaved with the ones for the first call. > > Sorry, I don't know what you mean. Can you explain? What I mean is: When you start a call, as you move through the stages of processing it the appropriate interceptors will be called. When you get to the point where preinvoke needs to be called on a servant locator, you are potentially beginning another orb-mediated call, and so a nested set of interceptor calls will be made for the preinvoke call itself. Once that is complete and the servant has been obtained, the interceptor calls for subsequent steps in the original call will be made. There is no reason that this need be a problem, though I imagine there may be implementation strategies that would not support it. Also note that this nested orb-mediated call need not stop at one level. While perverse, it is legal for the object representing the servant locator to itself require activation via another level of servant manager, and possibly for that to require POA activation via an orb-mediated AdapterActivator. (And while I don't really expect anyone to do this sort of thing in practice, I have tested it.) > > > - an orb mediated servant locator can make it impossible > for the servant > > locator to run in the same thread as the call on the > located servant. > > (They can be in different POAs, with incompatible > threading policies.) > > According to the spec, that would appear to be illegal. For > one, the spec > requires that preinvoke, the operation, and postinvoke must run in the > same thread. Second, if a servant locator is called on a POA to locate > a servant, that servant must be activated on that same POA (otherwise, > the servant locator wouldn't have been called for that POA). It seems to me that these rules about what thread something must run in have introduced inconsistencies into the specification. I know there was a lot of discussion and disagreement about when and if collocated calls can run in the thread of the caller - issues around SINGLE_THREAD_MODEL. If you interpret SINGLE_THREAD_MODEL to only require mutual exclusion of all invocations on that poa (rather than actually requiring those invocations to run in a single thread), then collocated calls can in general run in the thread of the caller. But once you start making requirements that certain things run in the "main thread", then some collocated invocations may require thread switching. This in turn can violate the requirement that preinvoke, the operation, and postinvoke all run in a single thread. This isn't primarily an issue for the interceptors ftf, but it does seem to be an issue in general. CORBA has at best a very incomplete notion of thread, and it probably has to stay that way in order to permit support by a wide range of languages, operating systems, etc. That need to be vague seems in conflict with the desire (primarily by OTS) to constrain some things to run in a single thread. Frankly I would prefer to see this pushed back on OTS to loosen their restrictions. Paul From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Issue 3619 Date: Thu, 25 May 2000 18:55:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 'Mbd9,Y[d9B_>e9_Wm!! > From: Michi Henning [mailto:michi@ooc.com.au] > Sure, I understand. But then, you might as well wait until > after postinvoke() > before sending those fragments, I think. So, as far as I can > see, requiring > the final interception point to run in the same thread as postinvoke > wouldn't cost anything extra. I agree. I think we have simply gotten off on a tangent about marshalling that isn't especially relevant to the issue of where thread changing can occur. Paul Date: Fri, 26 May 2000 07:38:21 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interceptors-ftf@omg.org Subject: RE: Issue 3619 In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BECC@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: -L~e9;Y*!!+Qgd9+f:e9 On Thu, 25 May 2000, Paul Kyzivat wrote: > > So, I see marshaling of fragments as an advantage only if we you use > > the AOM when there is no postinvoke call. But then, all of > > the operation > > reply is held completely in buffers until the operation > > returns control > > to the skeleton anyway, so there seems little point in > > fragmenting anything at that point, no? > > No. > > If you have a call with some very big arguments, it is unavoidable that > those arguments must be in memory, in their language binding representation, > once. > > What fragmentation does is eliminate the need for another full copy of those > arguments to simultaneously be in memory a second time, in marshalled form. > Instead, there is a bounded additional cost - the size of one fragment. Sure, I understand. But then, you might as well wait until after postinvoke() before sending those fragments, I think. So, as far as I can see, requiring the final interception point to run in the same thread as postinvoke wouldn't cost anything extra. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 25 May 2000 21:22:19 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: butek@us.ibm.com, interceptors-ftf@omg.org, Matthew Mihic , Eric Newcomer Subject: Re: Issue 3619 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: e6f!!R;=e9M6#!!bK*e9 From a purely POA perspective, its hard to argue with the convenience of just requiring all these intercept points to be called in the same thread. But there are other types of object adapters, some of which we may want to standardize some day. One type that would become unimplementable with this kind of constraint is an OA that supported event driven methods, where a thread is not tied up while the method is waiting for some long term event to occur. The POA can't do this, but that doesn't mean ORBs shouldn't be able to do it through some other OA interface. One example of where this kind of OA would be useful would be in building pull suppliers for an event or notification service. This kind of server side functionality would nicely complement the asynchronous invocation options now available on the client side. I see no reason why portable interceptors shouldn't work with such an OA, as long as we don't start adding threading constraints that aren't absolutely neccessary. -Bob Michi Henning wrote: > > On Wed, 24 May 2000, Bob Kukura wrote: > > > I must have somehow got confused about this. Matt Mihic cleared it up > > for me. In our C++ ORB, we do not marshal or send the reply until after > > postinvoke has returned. We do stream the reply as we marshal it, using > > fragments if appropriate. Our Java ORB's stream based portable > > skeletons may be another matter, and I don't make any claim to > > understand exactly how those work. I apologize for the confusion. > > Is it a big deal then to call the interceptor outgoing interception > point in the same thread? The way I see it, the cost of keeping the > same thread is less than doing a context switch. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Fri, 26 May 2000 12:33:22 +1000 (EST) From: Michi Henning To: Bob Kukura cc: butek@us.ibm.com, interceptors-ftf@omg.org, Matthew Mihic , Eric Newcomer Subject: Re: Issue 3619 In-Reply-To: <392DD1CA.26B74A0E@iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Cmg!!b^pd9WF2e9+~T!! On Thu, 25 May 2000, Bob Kukura wrote: > From a purely POA perspective, its hard to argue with the convenience > of just requiring all these intercept points to be called in the same > thread. But there are other types of object adapters, some of which we > may want to standardize some day. One type that would become > unimplementable with this kind of constraint is an OA that supported > event driven methods, where a thread is not tied up while the method is > waiting for some long term event to occur. The POA can't do this, but > that doesn't mean ORBs shouldn't be able to do it through some other OA > interface. Sure. Basically, the suggestion I made was motivated by the need that for OTS, thread-specific things have to happen with XA. In addition, the *POA* spec already says that preinvoke, the operation, and postinvoke must run in the same thread. From that, I figured that it won't constrain anyone unduly to require that the receive_request and the final interception point also run in the same thread. Now, all of this is directed at the POA only. Clearly, a totally different object adapter might have a very different view of threads. So, why not limit the PI threading requirement to the POA? That's really all I'm after. > One example of where this kind of OA would be useful would > be in building pull suppliers for an event or notification service. > This kind of server side functionality would nicely complement the > asynchronous invocation options now available on the client side. I > see > no reason why portable interceptors shouldn't work with such an OA, > as > long as we don't start adding threading constraints that aren't > absolutely neccessary. OK, I see your point. Would limiting the threading constraints to the POA address your concern? I agree that we can't impose arbitrary limitations on arbitrary and unknown object adapters. However, I think we can sensibly do this for the POA. Cheers, Michi. From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA10508; Wed, 31 May 2000 10:50:43 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id LAA26404; Wed, 31 May 2000 11:10:23 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568F0.0052652E ; Wed, 31 May 2000 10:59:58 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org, Matthew Mihic , Eric Newcomer Message-ID: <852568F0.005262BB.00@d54mta04.raleigh.ibm.com> Date: Wed, 31 May 2000 10:59:41 -0400 Subject: Re: Issue 3619 Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 8]m!!HZ`d9oX^d9L)i!! Michi Henning on 05/25/2000 09:33:22 PM > > On Thu, 25 May 2000, Bob Kukura wrote: > > > From a purely POA perspective, its hard to argue with the convenience > > of just requiring all these intercept points to be called in the same > > thread. But there are other types of object adapters, some of which we > > may want to standardize some day. One type that would become > > unimplementable with this kind of constraint is an OA that supported > > event driven methods, where a thread is not tied up while the method is > > waiting for some long term event to occur. The POA can't do this, but > > that doesn't mean ORBs shouldn't be able to do it through some other OA > > interface. > > Sure. Basically, the suggestion I made was motivated by the need that > for OTS, thread-specific things have to happen with XA. In addition, > the *POA* spec already says that preinvoke, the operation, and postinvoke > must run in the same thread. From that, I figured that it won't constrain > anyone unduly to require that the receive_request and the final interception > point also run in the same thread. > > Now, all of this is directed at the POA only. Clearly, a totally different > object adapter might have a very different view of threads. > > So, why not limit the PI threading requirement to the POA? That's really > all I'm after. > Limiting the threading requirement to the POA really bothers me. This forces interceptors to take into account whether or not there's a POA, even if they don't care. A logging interceptor, for example, may not care if there's a POA, and it may like to take advantage of the current state of affairs which dictate that each interception point is effectively running in its own thread. It can do all sorts of odd things with the PICurrent and know that it won't affect any other interception point. But if we now say this model doesn't exist with a POA, the logging interceptor has to determine what model it is running under and work differently in different circumstances. The logging interceptor effectively becomes two interceptors: a non-POA logging interceptor and a POA logging interceptor. I don't believe we can conditionally say that interception points may or may not run in the same thread. We have to clearly choose one way or the other. Russell Butek butek@us.ibm.com Date: Wed, 31 May 2000 09:21:06 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: butek@us.ibm.com CC: interceptors-ftf@omg.org, Matthew Mihic , Eric Newcomer Subject: Re: Issue 3619 References: <852568F0.005262BB.00@d54mta04.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: %D)!!c]9e9d,Yd9nXAe9 > I don't believe we can conditionally say that interception points may or > may not run in the same thread. We have to clearly choose one way or the > other. Well, if it can't be conditional then it would seem the transactions viz-a-viz the POA would force the spec to say they all run in the same thread which limits other adapters. It seems that a condition is maybe the least of evils? H Date: Tue, 25 Jul 2000 12:12:56 -0230 From: Matthew Newhook To: interceptors-ftf@omg.org Subject: issue 3619 Message-ID: <20000725121256.B28324@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us Content-Type: text/plain; charset=us-ascii X-UIDL: '-,!!O^^d9^dPd9CSp!! Hi, What is the status of this issue? Looking through the archive Russell made a specific proposal... Why not vote on that? 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 Date: Tue, 25 Jul 2000 08:42:37 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: interceptors-ftf@omg.org Subject: Re: issue 3619 References: <20000725121256.B28324@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: CFZ!!3kO!!G^a!!GSS!! Could you dig out the proposal from the archive, shine it up a bit if needed and send to us to include in the next vote. Michi said he was going to submit the proposal but I haven't heard from him. Thanks, Harold Matthew Newhook wrote: > > Hi, > > What is the status of this issue? Looking through the archive Russell > made a specific proposal... Why not vote on that? > > 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 Date: Tue, 25 Jul 2000 13:18:12 -0230 From: Matthew Newhook To: Harold Carr Cc: interceptors-ftf@omg.org Subject: Re: issue 3619 Message-ID: <20000725131812.A29342@ooc.com> References: <20000725121256.B28324@ooc.com> <397DB56D.FE23AA3@sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <397DB56D.FE23AA3@sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: (%ld9YQUd98YMe9JML!! Hi, On Tue, Jul 25, 2000 at 08:42:37AM -0700, Harold Carr wrote: > Could you dig out the proposal from the archive, shine it up a bit if > needed and send to us to include in the next vote. Michi said he was > going to submit the proposal but I haven't heard from him. Well, Russell had a concrete proposal in there that looked good. That's a cut & paste job. > Thanks, > Harold Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Tue, 25 Jul 2000 08:55:57 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: interceptors-ftf@omg.org Subject: Re: issue 3619 References: <20000725121256.B28324@ooc.com> <397DB56D.FE23AA3@sun.com> <20000725131812.A29342@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: b~0e9]A'e9;UD!!$b,!! As one could imagine, just getting the vote together, etc., is quite time consuming - that in addition to my other duties. What I was asking is for someone to take the time and submit a proposal. If you found one you liked, perhaps you could take the time to cut and paste and mail it to us. That would save me some time. I would greatly appreciate the help. Thanks, Harold Matthew Newhook wrote: > > Hi, > > On Tue, Jul 25, 2000 at 08:42:37AM -0700, Harold Carr wrote: > > Could you dig out the proposal from the archive, shine it up a bit if > > needed and send to us to include in the next vote. Michi said he was > > going to submit the proposal but I haven't heard from him. > > Well, Russell had a concrete proposal in there that looked good. That's > a cut & paste job. > > > Thanks, > > Harold > > Matthew > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Thu, 3 Aug 2000 10:46:12 +1000 (EST) From: Michi Henning To: Bob Kukura cc: Harold Carr , interceptors-ftf@omg.org Subject: Re: Vote 6 is now open In-Reply-To: <398862B0.9F04F704@iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Qh"e9[LH!!e(#e9B;"!! On Wed, 2 Aug 2000, Bob Kukura wrote: > 3619 - No. This is fine for the POA, but there may be other object > adapters where these kinds of threading constraints are not > possible. Bob, I don't think the resolution constrains other adapters. The text says: If a POA and a servant locator are present, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ So, the resolution imposes no constraints on other adapters. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 02 Aug 2000 22:27:19 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Harold Carr , interceptors-ftf@omg.org Subject: Re: Vote 6 is now open References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 4gM!!Vi'!!X]E!! Michi, I agree the resolution does not constrain other adapters. The problem is that it encourages people to write ORB service implementations that will not work properly with adapters that don't have this constraint. -Bob Michi Henning wrote: > > On Wed, 2 Aug 2000, Bob Kukura wrote: > > > 3619 - No. This is fine for the POA, but there may be other object > > adapters where these kinds of threading constraints are not possible. > > Bob, I don't think the resolution constrains other adapters. The text > says: > > If a POA and a servant locator are present, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > So, the resolution imposes no constraints on other adapters. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 3 Aug 2000 12:33:47 +1000 (EST) From: Michi Henning To: Bob Kukura cc: Harold Carr , interceptors-ftf@omg.org Subject: Re: Vote 6 is now open In-Reply-To: <3988D887.6B2C64E9@iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: J3L!!e/3!!:VOe9R0!e9 On Wed, 2 Aug 2000, Bob Kukura wrote: > Michi, > > I agree the resolution does not constrain other adapters. The > problem is > that it encourages people to write ORB service implementations that > will > not work properly with adapters that don't have this constraint. I see your point. Could we make a friendly amendment to this such that we add some words of caution? For example: Note that receive_request, preinvoke, the operation, post_invoke, and send_reply/send_exception/send_other are guaranteed to execute in the same thread only for implementations using the Portable Object Adapter. For other, non-portable object adapters, these threading guarantees may not apply. I would be inclined to also add a requirement to this along the following lines. (I think we should vote on this separately): For implementations providing such adapters, the ORB shall document what threading guarantees (if any) are provided for these adapters when used in conjunction with interceptors. Would that be acceptable? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html