Issue 3435: Interceptors and finalization (interceptors-rtf) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: the current PI spec doesn't give interceptors any chance to finalize themselves. As far as interceptors are concerned, the process simply disappears. That's rather bad news. For example, interceptors may allocate memory, open files, or do similar things with other resources. If interceptors are not given a chance to finalize themselves, that means they cannot clean up those resources. Depending on the environment, that can be positively disastrous. For example, in many environments, disappearing without freeing memory first causes a permanent and hard memory leak because there is no operating system to clean up after a task or process. It appears that PI needs to add a finalization call and define when exactly that call runs for client- and server-side interceptors. Resolution: Incorporate change and close issue. Revised Text: Add to 21.2: : Add to 21.2: module PortableInterceptor { local interface Interceptor { readonly attribute string name; void destroy(); }; }; Add a description of the destroy() operation. This method is called during ORB::destroy(). When an application calls ORB::destroy, the ORB 1) waits for all requests in progress to complete 2) calls the Interceptor::destroy() operation for each interceptor 3) completes destruction of the ORB Method invocations from within Interceptor::destroy() on object references for objects implemented on the ORB being destroyed result in undefined behavior. However, method invocations on objects implemented on an ORB other than the one being destroyed are permitted. (This means that the ORB being destroyed is still capable of acting as a client, but not as a server.) In section to 4.2.3.5: After paragraph: If destroy is called on an ORB that has not been shut down, it will start the shut down process and block until the ORB has shut down before it destroys the ORB. If an application calls destroy in a thread that is currently servicing an invocation, the BAD_INV_ORDER system exception will be raised with the OMG minor code 3, since blocking would result in a deadlock. Add: If interceptors are registered with the ORB being destroyed, the Interceptor::destroy() operation is invoked on each interceptor (see section 21.2). module PortableInterceptor { local interface Interceptor { readonly attribute string name; void destroy(); }; }; Add a description of the destroy() operation. This method is called during ORB::destroy(). When an application calls ORB::destroy, the ORB 1) waits for all requests in progress to complete 2) calls the Interceptor::destroy() operation for each interceptor 3) completes destruction of the ORB Method invocations from within Interceptor::destroy() on object references for objects implemented on the ORB being destroyed result in undefined behavior. However, method invocations on objects implemented on an ORB other than the one being destroyed are permitted. (This means that the ORB being destroyed is still capable of acting as a client, but not as a server.) In section to 4.2.3.5: After paragraph: If destroy is called on an ORB that has not been shut down, it will start the shut down process and block until the ORB has shut down before it destroys the ORB. If an application calls destroy in a thread that is currently servicing an invocation, the BAD_INV_ORDER system exception will be raised with the OMG minor code 3, since blocking would result in a deadlock. Add: If interceptors are registered with the ORB being destroyed, the Interceptor::destroy() operation is invoked on each interceptor (see section 21.2). Actions taken: March 22, 2000: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== ]Date: Wed, 22 Mar 2000 14:01:07 +1000 (EST) From: Michi Henning Reply-To: interceptors-ftf@omg.org To: interceptors-ftf@omg.org cc: issues@omg.org Subject: Interceptors and finalization Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: bI8e9l"8e9_0e!!R1Qd9 Hi, the current PI spec doesn't give interceptors any chance to finalize themselves. As far as interceptors are concerned, the process simply disappears. That's rather bad news. For example, interceptors may allocate memory, open files, or do similar things with other resources. If interceptors are not given a chance to finalize themselves, that means they cannot clean up those resources. Depending on the environment, that can be positively disastrous. For example, in many environments, disappearing without freeing memory first causes a permanent and hard memory leak because there is no operating system to clean up after a task or process. It appears that PI needs to add a finalization call and define when exactly that call runs for client- and server-side interceptors. 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 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568AA.0048C447.00@d54mta08.raleigh.ibm.com> Date: Wed, 22 Mar 2000 07:06:39 -0600 Subject: Re: Interceptors and finalization Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: NV>e9=j-!!O(2e9j0Ne9 This seems reasonable. Interceptors are attached to the ORB, so their lifespan should be the same as the ORBs. Do we want to dictate details like: when orb.shutdown is called the interceptor finailizers are called. Or do we want to keep it vague and up to the ORB implementors and say something like: when the ORB object goes away, the interceptor finalizers are called. My guess is we'll have to do the latter since orb.shutdown need not be called on the client. Russell Butek butek@us.ibm.com Michi Henning on 03/21/2000 10:01:07 PM Please respond to interceptors-ftf@omg.org To: interceptors-ftf@omg.org cc: issues@omg.org Subject: Interceptors and finalization Hi, the current PI spec doesn't give interceptors any chance to finalize themselves. As far as interceptors are concerned, the process simply disappears. That's rather bad news. For example, interceptors may allocate memory, open files, or do similar things with other resources. If interceptors are not given a chance to finalize themselves, that means they cannot clean up those resources. Depending on the environment, that can be positively disastrous. For example, in many environments, disappearing without freeing memory first causes a permanent and hard memory leak because there is no operating system to clean up after a task or process. It appears that PI needs to add a finalization call and define when exactly that call runs for client- and server-side interceptors. 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, 22 Mar 2000 09:37:50 -0330 From: Matthew Newhook To: interceptors-ftf@omg.org Cc: issues@omg.org Subject: Re: Interceptors and finalization Message-ID: <20000322093750.A24094@ooc.com> References: Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: D\md9ZW6e9+7m!!MTB!! Hi Michi, On Wed, Mar 22, 2000 at 02:01:07PM +1000, Michi Henning wrote: > Hi, > > the current PI spec doesn't give interceptors any chance to finalize > themselves. As far as interceptors are concerned, the process simply > disappears. The ORB disappears ;) > That's rather bad news. For example, interceptors may allocate > memory, open files, or do similar things with other resources. If > interceptors > are not given a chance to finalize themselves, that means they > cannot > clean up those resources. Depending on the environment, that can be > positively disastrous. For example, in many environments, > disappearing > without freeing memory first causes a permanent and hard memory leak > because > there is no operating system to clean up after a task or process. > > It appears that PI needs to add a finalization call and define when > exactly > that call runs for client- and server-side interceptors. I guess the intent was that the standard programming lanaguage constructs would suffice here... That is destructors in C++ and finalize() in Java. However, I guess this is probably a problem in some languages (like C) that don't have such a concept... > 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 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 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 22 Mar 2000 08:15:44 -0500 (EST) From: Polar Humenn To: interceptors-ftf@omg.org Subject: Re: Interceptors and finalization In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 5]I!!/IPe9fUh!!"BX!! Michi, and some knowledgable POA people. I have couple of questions: We have in one of the interceptors, an adapter_id, and an object_id, and also a get_server_policy(). First, assuming the interceptor knows its using a POA architecture I don't believe there is a STANDARD way to locate the POA for the server? It wouldn't be much of a PORTABLE interceptor if we cannot. Assuming that we can locate the POA, then I assume that it is possible to locate the servant using that id? Servant s = POA.id_to_servant(object_id); Correct? Next: Although we have a get_server_policy() on the interceptor, there is NO such operation on the POA, correct? Is this a good idea? Next question is the cruxt of it all: Is it proper to call on the located Servant in the interceptor? An interceptor may have intimate knowledge of the Servant implemenation and base access control on its contents, such as an account number, etc. Would this be allowed with the current architecture. I hope so. If not, what must we do? I am correct in assuming that calls directly on the Servant are not mediated by any interceptor? Thanks, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Wed, 22 Mar 2000 08:03:03 -0800 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 Subject: Re: Interceptors and finalization References: <852568AA.0048C447.00@d54mta08.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: $N1!!Z&)!!X16e9l%-e9 It probably would be somewhere between. Finalizers would be called on certain specific conditions (e.g., orb.shutdown) AND if the orb is reclaimed in GCed language, AND ?... H > Interceptors are attached to the ORB, so their lifespan should be the same > as the ORBs. Do we want to dictate details like: when orb.shutdown is > called the interceptor finailizers are called. Or do we want to keep it > vague and up to the ORB implementors and say something like: when the ORB > object goes away, the interceptor finalizers are called. My guess is we'll > have to do the latter since orb.shutdown need not be called on the client. From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Interceptors and finalization Date: Wed, 22 Mar 2000 12:23:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: >_A!!!Tm!!_]p!!/7Le9 > From: Polar Humenn [mailto:polar@adiron.com] > First, assuming the interceptor knows its using a POA > architecture I don't > believe there is a STANDARD way to locate the POA for the server? > > It wouldn't be much of a PORTABLE interceptor if we cannot. I want to hear Michi's answer that one. > Assuming that > we can locate the POA, then I assume that it is possible to locate > the > servant using that id? > > Servant s = POA.id_to_servant(object_id); > > Correct? Not necessarily. It depends on POA policies. Either RETAIN or USE_DEFAULT_SERVANT are required for this to work. If the servant isn't in the active object map, and there isn't a default servant, this will fail. So, none of the cases that require calling a ServantManager to find the servant will work. If you want access to the servant, I think we need to have an explicit interceptor point that is called after the servant is selected, but before the method is called on that servant. > Next question is the cruxt of it all: > > Is it proper to call on the located Servant in the interceptor? > > An interceptor may have intimate knowledge of the Servant > implemenation > and base access control on its contents, such as an account > number, etc. > Would this be allowed with the current architecture. I hope > so. If not, > what must we do? I think this is undefined currently, and must be discussed. Date: Wed, 22 Mar 2000 10:01:33 -0800 (PST) From: Sam Aslam-Mir Message-Id: <200003221801.KAA24011@matterhorn.expersoft.com> To: interceptors-ftf@omg.org, matthew@ooc.com, jsinger@expersoft.com Subject: Re: Interceptors and finalization Cc: issues@omg.org Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-MD5: WPyVshnK4MpKowOynb918A== Content-Type: text/plain; charset=us-ascii X-UIDL: gEB!!`;Je9p$^d9+/>e9 Errm, i know that i usually dont have much to say, (largely out of complete and utter incompetence and ignorance, but thats another story... ) but Michi made a few points that really warrant attention - leaving aside languages having Gc capabilities (though dangling references can be a problem here too, and you can still get a leak) and desctructors in C++, there were a few other very valid points Michi made as follows: > For example, interceptors may allocate > memory, open files, or do similar things with other resources. e.g file-descriptors not released in Java. This can cause a serious problem > If interceptors > are not given a chance to finalize themselves, that means they > cannot > clean up those resources. Depending on the environment, that can be > positively disastrous. For example, in many environments, > disappearing > without freeing memory first causes a permanent and hard memory leak > e.g. vxworks > because there is no operating system to clean up after a task or process. all non-memory-protected OS's and those environments (e.g. embedded) where theres almost no demarcation between OS and application because all the parts of OS are also the application > It appears that PI needs to add a finalization call and define when exactly > that call runs for client- and server-side interceptors. I agree therefore. There are also languages that have various degrees of Gc (weak/strong refs), and then there's that old smalltalk language (anybody remember that ;-) ), plus there's the C mapping - how would a C orb handle this problem ? Sam Date: Thu, 23 Mar 2000 08:52:06 +1000 (EST) From: Michi Henning To: Matthew Newhook cc: interceptors-ftf@omg.org, issues@omg.org Subject: Re: Interceptors and finalization In-Reply-To: <20000322093750.A24094@ooc.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Bp(!!#:De9i\Zd9LJW!! On Wed, 22 Mar 2000, Matthew Newhook wrote: > > It appears that PI needs to add a finalization call and define when exactly > > that call runs for client- and server-side interceptors. > > I guess the intent was that the standard programming lanaguage constructs > would suffice here... That is destructors in C++ and finalize() in Java. > However, I guess this is probably a problem in some languages (like C) > that don't have such a concept... Precisely. And, you can't rely on destructors anyway because there is no such thing in non-OO languages. And, let's be honest, there is no such thing in Java either, because Java doesn't guarantee that destructors will be called. If an interceptor holds resources that require any sort of explicit cleanup, those resources are leaked unless we add a finalization call of some kind. 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, 23 Mar 2000 15:52:08 +1000 (EST) From: Michi Henning To: Polar Humenn cc: interceptors-ftf@omg.org Subject: Re: Interceptors and finalization In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 9Z\!!*P/!!iUIe9gR_d9 On Wed, 22 Mar 2000, Polar Humenn wrote: > I have couple of questions: > > We have in one of the interceptors, an adapter_id, and an object_id, > and > also a get_server_policy(). > > First, assuming the interceptor knows its using a POA architecture I > don't > believe there is a STANDARD way to locate the POA for the server? Hmmm... I think there is: call resolve_initial_references("POACurrent") and then call get_POA(). The assumption is that the interceptor knows that a POA is used for the request (as opposed to some other kind of adapter). > It wouldn't be much of a PORTABLE interceptor if we cannot. Assuming that > we can locate the POA, then I assume that it is possible to locate the > servant using that id? > > Servant s = POA.id_to_servant(object_id); > > Correct? I think that's right, yes. > Next: > > Although we have a get_server_policy() on the interceptor, there > is NO such operation on the POA, correct? Is this a good idea? It at least implies hidden communication between the get_server_policy() implementation and the POA implementation. It's not particularly clean, no. On the other hand, I don't think that this presents any real implementation difficulty. > Next question is the cruxt of it all: > > Is it proper to call on the located Servant in the interceptor? > > An interceptor may have intimate knowledge of the Servant > implemenation > and base access control on its contents, such as an account number, > etc. > Would this be allowed with the current architecture. I hope so. If > not, > what must we do? As far as I can see, it would be legal to call the servant *directly* (not via it's object reference). > I am correct in assuming that calls directly on the Servant are not > mediated by any interceptor? If you don't call via a reference, the ORB has no idea that the call is happening and, therefore, can't mediate it anyway. 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, 23 Mar 2000 16:01:17 +1000 (EST) From: Michi Henning To: butek@us.ibm.com cc: interceptors-ftf@omg.org Subject: Re: Interceptors and finalization In-Reply-To: <852568AA.0048C447.00@d54mta08.raleigh.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ?XLd9$Jmd9bY;!!TGI!! On Wed, 22 Mar 2000 butek@us.ibm.com wrote: > This seems reasonable. > > Interceptors are attached to the ORB, so their lifespan should be > the same > as the ORBs. Do we want to dictate details like: when orb.shutdown > is > called the interceptor finailizers are called. Or do we want to > keep it > vague and up to the ORB implementors and say something like: when > the ORB > object goes away, the interceptor finalizers are called. My guess > is we'll > have to do the latter since orb.shutdown need not be called on the > client. I'm not comfortable with the vague version of this, but I agree that it's difficult to have a better one in the absence of defined ORB states. Maybe defining the ORB states is what we should do or, alternatively, allow the application to explicitly make a call that invokes the finalizers? 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, 23 Mar 2000 16:33:17 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interceptors-ftf@omg.org Subject: RE: Interceptors and finalization In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BD26@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: #9"e9l~/e9R/~!!>(^!! On Wed, 22 Mar 2000, Paul Kyzivat wrote: > > Assuming that > > we can locate the POA, then I assume that it is possible to locate > the > > servant using that id? > > > > Servant s = POA.id_to_servant(object_id); > > > > Correct? > > Not necessarily. It depends on POA policies. Either RETAIN or > USE_DEFAULT_SERVANT are required for this to work. If the servant > isn't in > the active object map, and there isn't a default servant, this will > fail. > So, none of the cases that require calling a ServantManager to find > the > servant will work. Paul, are you sure that's correct? Given that we are in the receive_request() interception point, the servant must have been located already, otherwise the parameters wouldn't be available, no? > If you want access to the servant, I think we need to have an explicit > interceptor point that is called after the servant is selected, but before > the method is called on that servant. I thought that was the case for receive_request()? > > Next question is the cruxt of it all: > > > > Is it proper to call on the located Servant in the > interceptor? > > > > An interceptor may have intimate knowledge of the Servant > > implemenation > > and base access control on its contents, such as an account > > number, etc. > > Would this be allowed with the current architecture. I hope > > so. If not, > > what must we do? > > I think this is undefined currently, and must be discussed. Is it really? I would have thought that calling id_to_servant() would work and that I can then call into the servant. But maybe I'm missing something... 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: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Interceptors and finalization Date: Thu, 23 Mar 2000 09:29:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: CPm!!9)@!!B7R!!)6d!! Status: U > From: Michi Henning [mailto:michi@ooc.com.au] > > First, assuming the interceptor knows its using a POA > architecture I don't > > believe there is a STANDARD way to locate the POA for the server? > > Hmmm... I think there is: call > resolve_initial_references("POACurrent") > and then call get_POA(). The assumption is that the interceptor > knows > that a POA is used for the request (as opposed to some other > kind of adapter). Thanks Michi - I didn't think of that one. One problem solved! There is still the issue of getting the servant. Perhaps POACurrent should be changed to make that available too. From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Interceptors and finalization Date: Thu, 23 Mar 2000 09:54:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 3Dk!!GXCe9+)Qe9G#K!! > From: Michi Henning [mailto:michi@ooc.com.au] > Paul, are you sure that's correct? Given that we are in the > receive_request() > interception point, the servant must have been located > already, otherwise > the parameters wouldn't be available, no? Section 11.3.8.24 (id_to_servant) states: "This operation requires the RETAIN policy or the USE_DEFAULT_SERVANT policy. If neither policy is present, the WrongPolicy exception is raised. If the POA has the RETAIN policy and the specified ObjectId is in the Active Object Map, this operation returns the servant associated with that object in the Active Object Map. Otherwise, if the POA has the USE_DEFAULT_SERVANT policy and a default servant has been registered with the POA, this operation returns the default servant. Otherwise the ObjectNotActive exception is raised." > > If you want access to the servant, I think we need to have > an explicit > > interceptor point that is called after the servant is > selected, but before > > the method is called on that servant. > > I thought that was the case for receive_request()? I hadn't double checked how constrained that point was when I wrote this. I now agree that receive_request is required to run at the right time. > Is it really? I would have thought that calling > id_to_servant() would work > and that I can then call into the servant. But maybe I'm > missing something... As noted above, I don't think id_to_servant works. But if the interceptor gets access to the servant I personally see no reason why it shouldn't call it. But perhaps others feel differently. Date: Thu, 23 Mar 2000 17:02:49 -0500 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Polar Humenn , interceptors-ftf@omg.org Subject: Re: Interceptors and finalization References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &=`d9_Hbd9jbj!!i&E!! Michi Henning wrote: > > On Wed, 22 Mar 2000, Polar Humenn wrote: > > > I have couple of questions: > > > > We have in one of the interceptors, an adapter_id, and an > object_id, and > > also a get_server_policy(). > > > > First, assuming the interceptor knows its using a POA architecture > I don't > > believe there is a STANDARD way to locate the POA for the server? > > Hmmm... I think there is: call > resolve_initial_references("POACurrent") > and then call get_POA(). The assumption is that the interceptor > knows > that a POA is used for the request (as opposed to some other kind of > adapter). I would not expect this to work. Unless something crept in that I am not aware of, the POA Current is not guaranteed to be set up in the context in which interceptors are called. Someone else may have a definitive answer on this, though. Since the interceptors can be called in different threads than the servant, requiring it to be set up might add rarely useful overhead to all invocations. -Bob From: Paul Kyzivat To: Polar Humenn , interceptors-ftf@omg.org Subject: RE: Interceptors and finalization Date: Thu, 23 Mar 2000 19:23:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: QiPd9;&Zd9K]od9Rf8e9 > From: Bob Kukura [mailto:kukura@iona.com] > I would not expect this to work. Unless something crept in that I am > not aware of, the POA Current is not guaranteed to be set up in the > context in which interceptors are called. Someone else may have a > definitive answer on this, though. Since the interceptors > can be called > in different threads than the servant, requiring it to be set up might > add rarely useful overhead to all invocations. I know some of the interceptors can be called in other threads. But isn't it reasonable to assume the receive_request interceptor will be called in the same thread as the actual call? After all, it can't be called until the servant has been chosen. Somehow, the security interceptor needs a way to get access to the servant. Date: Thu, 23 Mar 2000 21:31:20 -0500 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: Polar Humenn , interceptors-ftf@omg.org Subject: Re: Interceptors and finalization References: <9B164B713EE9D211B6DC0090273CEEA926BD4B@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: N7fd9Z9^d9$n1!!=F[d9 I was on vacation the past week and easily could have missed a relevant email, but I have not seen a compelling argument that the security service needs access to the servant. Could someone explain this, please, or forward me the email explaining it? I just don't see what a generic security service could usefully do with an application specific servant. -Bob Paul Kyzivat wrote: > > > From: Bob Kukura [mailto:kukura@iona.com] > > > I would not expect this to work. Unless something crept in that I > am > > not aware of, the POA Current is not guaranteed to be set up in > the > > context in which interceptors are called. Someone else may have a > > definitive answer on this, though. Since the interceptors > > can be called > > in different threads than the servant, requiring it to be set up > might > > add rarely useful overhead to all invocations. > > I know some of the interceptors can be called in other threads. > But isn't it reasonable to assume the receive_request interceptor > will be > called in the same thread as the actual call? After all, it can't be > called > until the servant has been chosen. > > Somehow, the security interceptor needs a way to get access to the > servant. Date: Fri, 24 Mar 2000 17:04:04 +1000 (EST) From: Michi Henning To: Bob Kukura cc: Polar Humenn , interceptors-ftf@omg.org Subject: Re: Interceptors and finalization In-Reply-To: <38DA9489.51FD4762@iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: "Ddd9$F~!!R6*e9=1[d9 On Thu, 23 Mar 2000, Bob Kukura wrote: > > Hmmm... I think there is: call resolve_initial_references("POACurrent") > > and then call get_POA(). The assumption is that the interceptor knows > > that a POA is used for the request (as opposed to some other kind of adapter). > > I would not expect this to work. Unless something crept in that I am > not aware of, the POA Current is not guaranteed to be set up in the > context in which interceptors are called. Someone else may have a > definitive answer on this, though. Since the interceptors can be called > in different threads than the servant, requiring it to be set up might > add rarely useful overhead to all invocations. I agree with you. I can't find anything in the current draft that would require POACurrent to be set up. I think the consequence is that, currently, it's impossible for an interceptor to call into the servant because it can't find out what the servant is... But, I also would like to know why an interceptor has to be able to call the servant. It seems a bit strange, given that the only functionality inside the servant should be the operations that the servant offers. I don't see why an interceptor would want to call those either... 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, 24 Mar 2000 17:21:36 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: Polar Humenn , interceptors-ftf@omg.org Subject: RE: Interceptors and finalization In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BD4B@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: oG;e95G-!!M]5e9A(@e9 On Thu, 23 Mar 2000, Paul Kyzivat wrote: > I know some of the interceptors can be called in other threads. > But isn't it reasonable to assume the receive_request interceptor > will be > called in the same thread as the actual call? After all, it can't be > called > until the servant has been chosen. No, not reasonable, at least not according to the current draft, which says for receive_request(): This interception point may or may not execute in the same thread as as the target invocation. 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: Interceptors and finalization Date: Fri, 24 Mar 2000 09:38:49 -0000 Message-ID: <002e01bf9574$c25b46d0$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: K?`!!*^E!!I7@!!`h4e9 Michi Henning wrote: > > On Thu, 23 Mar 2000, Paul Kyzivat wrote: > > > I know some of the interceptors can be called in other threads. > > But isn't it reasonable to assume the receive_request > interceptor will be > > called in the same thread as the actual call? After all, it > can't be called > > until the servant has been chosen. > > No, not reasonable, at least not according to the current draft, > which says > for receive_request(): > > This interception point may or may not execute in the same thread as > as the target invocation. > The receive_request() interceptor can read the RequestInfo's arguments attribute. This attribute isn't guaranteed to give anything useful (e.g. when the skeleton uses stream-based unmarshalling), but could if the skeleton uses DSI-based unmarshalling. In that case, the interceptor would have to be called from inside ServerRequest::arguments(), which is called from the skeleton, which is the base class of the servant. In that case, it's likely that the interceptor will run on the same thread. If an ORB that wants to make arguments available in these conditions, it will have to defer all calls of the interceptor until after it has located the servant (i.e. somewhere inside the POA), because that's when it discovers whether it's stream- or DSI-based. Again, it seems likely it will run on the same thread as the servant. Would we lose much by insisting that this interceptor, at least, runs on the servant's thread (except cleanliness, consistency, ...)? Regards Nick From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: nick.sharman@peerlogic.com cc: interceptors-ftf@omg.org Message-ID: <852568AC.004D5262.00@d54mta08.raleigh.ibm.com> Date: Fri, 24 Mar 2000 07:56:19 -0600 Subject: RE: Interceptors and finalization Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: E5Ee9P$J!!KW-!!p-Md9 In the example you give, yes, the interceptor would most likely run in the same thread as the servant. But in other non-DSI scenarios it may not. The ORB might have some thread pooling algorithm. Everything ORB-related might run in one thread, but then the servant invocation might be attached to a pooled thread. We don't want to restrict ORB vendors from implementing optimizations that they might consider useful. I originally suggested the same thing early on since that interception point would indeed run in the same thread on our implementation and that knowledge would make some of our proprietary transaction processing easier, but I was convinced that we should not force such a limitation on everyone. Russell Butek butek@us.ibm.com "Nick Sharman" on 03/24/2000 03:38:49 AM Please respond to nick.sharman@peerlogic.com To: interceptors-ftf@omg.org cc: Subject: RE: Interceptors and finalization Michi Henning wrote: > > On Thu, 23 Mar 2000, Paul Kyzivat wrote: > > > I know some of the interceptors can be called in other threads. > > But isn't it reasonable to assume the receive_request > interceptor will be > > called in the same thread as the actual call? After all, it > can't be called > > until the servant has been chosen. > > No, not reasonable, at least not according to the current draft, > which says > for receive_request(): > > This interception point may or may not execute in the same thread as > as the target invocation. > The receive_request() interceptor can read the RequestInfo's arguments attribute. This attribute isn't guaranteed to give anything useful (e.g. when the skeleton uses stream-based unmarshalling), but could if the skeleton uses DSI-based unmarshalling. In that case, the interceptor would have to be called from inside ServerRequest::arguments(), which is called from the skeleton, which is the base class of the servant. In that case, it's likely that the interceptor will run on the same thread. If an ORB that wants to make arguments available in these conditions, it will have to defer all calls of the interceptor until after it has located the servant (i.e. somewhere inside the POA), because that's when it discovers whether it's stream- or DSI-based. Again, it seems likely it will run on the same thread as the servant. Would we lose much by insisting that this interceptor, at least, runs on the servant's thread (except cleanliness, consistency, ...)? Regards Nick From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Interceptors and finalization Date: Fri, 24 Mar 2000 09:56:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: _hhd9Bmhd9$E$e98O]!! > From: Bob Kukura [mailto:kukura@iona.com] > I was on vacation the past week and easily could have missed > a relevant > email, but I have not seen a compelling argument that the security > service needs access to the servant. Could someone explain this, > please, or forward me the email explaining it? I just don't > see what a > generic security service could usefully do with an > application specific > servant. It mostly comes out of discussions at the Denver meeting. The primary issue is domain membership. If you don't want all objects in the server to be in the same domain, there needs to be some means to classify them into domain. For the same reason that the POA avoids keeping its own state regarding individual objects, the security service should also be able to do domain membership without maintaining per-object state of its own. Eventually this comes down to wanting to make the domain membership decision based on state of the actual object, and that means making calls on the servant. Of course this requires some user written code, that has knowledge of servant features, to be called from the security service. But that is simply an exit similar to a servant manager. Paul X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 22 Mar 2000 13:45:11 -0500 (EST) From: Polar Humenn To: Paul Kyzivat cc: interceptors-ftf@omg.org Subject: Re: Using a POA (was: Interceptors and finalization, sorry for the tack-on) In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BD26@bos1.noblenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: "eg!!dfN!!%@ed9cL^d9 On Wed, 22 Mar 2000, Paul Kyzivat wrote: > > From: Polar Humenn [mailto:polar@adiron.com] > > > First, assuming the interceptor knows its using a POA > > architecture I don't > > believe there is a STANDARD way to locate the POA for the server? > > > > It wouldn't be much of a PORTABLE interceptor if we cannot. > > I want to hear Michi's answer that one. Assuming that we don't want to recognize a POA in the interceptors by putting its type in there (or not preclude the use of a BOA by putting the POA type in there), this adapter id, should be able to be used to locate the POA for the servant. > > Assuming that > > we can locate the POA, then I assume that it is possible to locate > the > > servant using that id? > > > > Servant s = POA.id_to_servant(object_id); > > > > Correct? > > Not necessarily. It depends on POA policies. Either RETAIN or > USE_DEFAULT_SERVANT are required for this to work. If the servant > isn't in > the active object map, and there isn't a default servant, this will > fail. > So, none of the cases that require calling a ServantManager to find > the > servant will work. Okay, so is_to_servant(object_id) doesn't work if we must call a servant manager. What's the work around? > If you want access to the servant, I think we need to have an explicit > interceptor point that is called after the servant is selected, but before > the method is called on that servant. Hmmmm. I thought that is what that the current interceptor point was. > > Next question is the cruxt of it all: > > > > Is it proper to call on the located Servant in the > interceptor? > > > > An interceptor may have intimate knowledge of the Servant > > implemenation > > and base access control on its contents, such as an account > > number, etc. > > Would this be allowed with the current architecture. I hope > > so. If not, > > what must we do? > > I think this is undefined currently, and must be discussed. Okay. That needs to be discussed. How do we start? Anybody like to chime in? Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Using a POA (was: Interceptors and finalization, sorry for t he tack-on) Date: Wed, 22 Mar 2000 15:56:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: )"Z!!n*9!!d>$"!h`Ee9 > From: Polar Humenn [mailto:polar@adiron.com] > > > First, assuming the interceptor knows its using a POA > > > architecture I don't > > > believe there is a STANDARD way to locate the POA for the > server? > > > > > > It wouldn't be much of a PORTABLE interceptor if we cannot. > > > > I want to hear Michi's answer that one. > > Assuming that we don't want to recognize a POA in the interceptors > by > putting its type in there (or not preclude the use of a BOA > by putting the POA type in there), this adapter id, should be able > to be used to locate the POA for the servant. I'm still waiting to hear from Michi on this. But I agree with you - there should be a way to access the POA itself. At the moment I don't see any way to do that and retain opacity about whether a POA, BOA, or something else is used. I suppose there could be a PortableServerRequestInfo interface that derives from ServerRequestInfo and provides an accessor for the POA. Then the interceptor would need to narrow the argument to get the POA. > Okay, so is_to_servant(object_id) doesn't work if we must > call a servant manager. What's the work around? The only work around I can see is for the interceptor to provide access to the Servant. This suffers from some of the same problems (and solutions) as access to the POA. It has an added problem in that it will require some operation that returns a Servant. That may present some technical problems. > > > If you want access to the servant, I think we need to have > an explicit > > interceptor point that is called after the servant is > selected, but before > > the method is called on that servant. > > Hmmmm. I thought that is what that the current interceptor point > was. I guess so, but currently the Servant isn't made available. It needs to be. > > > > Next question is the cruxt of it all: > > > > > > Is it proper to call on the located Servant in the > interceptor? > > > > > > An interceptor may have intimate knowledge of the Servant > > > implemenation > > > and base access control on its contents, such as an account > > > number, etc. > > > Would this be allowed with the current architecture. I hope > > > so. If not, > > > what must we do? > > > > I think this is undefined currently, and must be discussed. > > Okay. That needs to be discussed. How do we start? > Anybody like to chime in? I think this should be kosher. The interceptor should be able to do anything it knows how to do with the servant, except destroy it. BTW, I see this is going to the interceptors-ftf list. But this is effectively joint business of interceptors and security, because the PI submission left it up to security to define added capabilities needed for security. Does anybody else in the security sig care about this? Paul Date: Wed, 22 Mar 2000 13:12:02 -0800 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interceptors-ftf@omg.org Subject: Re: Using a POA (was: Interceptors and finalization, sorry for the tack-on) References: <9B164B713EE9D211B6DC0090273CEEA926BD2C@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: AEP!!+P&e9#XSd96KI!! Paul Kyzivat wrote: > I suppose there could be a PortableServerRequestInfo interface that > derives from ServerRequestInfo and provides an accessor for the POA. > Then the interceptor would need to narrow the argument to get the > POA. Why have a derived interface? Why not just put in in ServerRequestInfo? Would it be possible to define a base ObjectAdapter interface and retrofit the POA to derive from it? H X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 22 Mar 2000 16:31:54 -0500 (EST) From: Polar Humenn To: Paul Kyzivat cc: interceptors-ftf@omg.org, secsig@omg.org Subject: RE: Using a POA (was: Interceptors and finalization, sorry for t he tack-on) In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BD2C@bos1.noblenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: mmed9`b_!!3-\!!d&:e9 Greetings, This thread is forwarded to secsig, and I continue correspondance with other Interceptor folks below; -Polar On Wed, 22 Mar 2000, Paul Kyzivat wrote: > > From: Polar Humenn [mailto:polar@adiron.com] > > > > > First, assuming the interceptor knows its using a POA > > > > architecture I don't > > > > believe there is a STANDARD way to locate the POA for the > server? > > > > > > > > It wouldn't be much of a PORTABLE interceptor if we cannot. > > > > > > I want to hear Michi's answer that one. > > > > Assuming that we don't want to recognize a POA in the interceptors > by > > putting its type in there (or not preclude the use of a BOA > > by putting the POA type in there), this adapter id, should be able > > to be used to locate the POA for the servant. > > I'm still waiting to hear from Michi on this. > But I agree with you - there should be a way to access the POA > itself. > At the moment I don't see any way to do that and retain opacity > about > whether a POA, BOA, or something else is used. > > I suppose there could be a PortableServerRequestInfo interface that > derives from ServerRequestInfo and provides an accessor for the POA. > Then the interceptor would need to narrow the argument to get the > POA. I don't see a problem with that. An extension that handles the POA, and may be an extension that handles the BOA as well? (although I don't think that is quite possible). > > Okay, so is_to_servant(object_id) doesn't work if we must > > call a servant manager. What's the work around? > > The only work around I can see is for the interceptor to provide > access to the Servant. This suffers from some of the same problems > (and solutions) as access to the POA. So the PortableServerRequestInfo can have the following attributes: readonly attribute PortableServer::POA the_poa; readonly attribute PortableServer::Servant the_servant; > > It has an added problem in that it will require some operation that > returns > a Servant. That may present some technical problems. I figured that. What kind of problems do you expect? > > > If you want access to the servant, I think we need to have > > an explicit > > > interceptor point that is called after the servant is > > selected, but before > > > the method is called on that servant. > > > > Hmmmm. I thought that is what that the current interceptor point > was. > > I guess so, but currently the Servant isn't made available. It needs > to be. Glad we agree. > > > > Next question is the cruxt of it all: > > > > > > > > Is it proper to call on the located Servant in the > > interceptor? > > > > > > > > An interceptor may have intimate knowledge of the Servant > > > > implemenation > > > > and base access control on its contents, such as an account > > > > number, etc. > > > > Would this be allowed with the current architecture. I hope > > > > so. If not, > > > > what must we do? > > > > > > I think this is undefined currently, and must be discussed. > > > > Okay. That needs to be discussed. How do we start? > > Anybody like to chime in? > > I think this should be kosher. > The interceptor should be able to do anything it knows how to do > with the > servant, except destroy it. Well, I guess we should say "shouldn't destroy it". Being pedantic, I doubt that we can stop that. Microsoft destroys internal things all the time :)! > BTW, I see this is going to the interceptors-ftf list. But this is > effectively joint business of interceptors and security, because the > PI > submission left it up to security to define added capabilities > needed for > security. Does anybody else in the security sig care about this? So far, just me, because I'm trying to help out on the Domain Management RFP response so that interceptors can be used (but not necessary) to get what we want out of it, as we were discussing in Denver. The secsig is now copied on this. What about POA people? Cheers, -Polar > > Paul > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Using a POA (was: Interceptors and finalization, sorry for t he tack-on) Date: Wed, 22 Mar 2000 16:41:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: T?(e96M/!!A:!!!f8ed9 > From: Harold Carr [mailto:harold.carr@sun.com] > > I suppose there could be a PortableServerRequestInfo interface that > > derives from ServerRequestInfo and provides an accessor for the POA. > > Then the interceptor would need to narrow the argument to > > get the POA. > > Why have a derived interface? Why not just put in in > ServerRequestInfo? That would be fine with me. I have been repeatedly been making the point that we only standardize one adapter type (POA) and provide nothing in the way of a framework that would suggest how to introduce other types. In that context it seems pointless to make provisions for other sorts of adapters. But it seems that people have been attempting to do just that, and I am trying to go along. This is a way to separate the POA specific features from the features that pertain to some abstract adapter. > > Would it be possible to define a base ObjectAdapter interface > and retrofit the POA to derive from it? I suppose we could consider that. But what capabilities would it have? Paul X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 22 Mar 2000 16:46:48 -0500 (EST) From: Polar Humenn To: Harold Carr cc: Paul Kyzivat , interceptors-ftf@omg.org Subject: Re: Using a POA (was: Interceptors and finalization, sorry for the tack-on) In-Reply-To: <38D93722.D9E1C86@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: HQ1e9K7L!!ePPe9++Rd9 On Wed, 22 Mar 2000, Harold Carr wrote: > Paul Kyzivat wrote: > > > I suppose there could be a PortableServerRequestInfo interface > that > > derives from ServerRequestInfo and provides an accessor for the > POA. > > Then the interceptor would need to narrow the argument to get the > POA. > > Why have a derived interface? Why not just put in in > ServerRequestInfo? > > Would it be possible to define a base ObjectAdapter interface > and retrofit the POA to derive from it? You would have to revamp the BOA as well (although I think the BOA is about as real as the ORB these days, PIDL and all that correct?). Also, with a BOA, an Object reference refers to the object implementation (i.e. servant) (at least in Java, I think), so that would cause some of the same problems. Is narrowing that much of a problem in the local case? Looks like a clean solution without having to modify the POA spec and implementations. > H > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: Paul Kyzivat To: interceptors-ftf@omg.org, secsig@omg.org Subject: RE: Using a POA (was: Interceptors and finalization, sorry for t he tack-on) Date: Wed, 22 Mar 2000 17:01:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ,']d9]$Ne906d!!VT>!! > From: Polar Humenn [mailto:polar@adiron.com] > So the PortableServerRequestInfo can have the following attributes: > > readonly attribute PortableServer::POA the_poa; > readonly attribute PortableServer::Servant the_servant; Yes, that is more or less what I had in mind. > > > > It has an added problem in that it will require some > operation that returns > > a Servant. That may present some technical problems. > > I figured that. What kind of problems do you expect? Each kind of native type (in this case Servant) has its own language mapping. So, every operation that takes such a type needs to support that custom mapping. It seems like this can work in general, but I am expecting to hear somebody raise a issue why it won't. > > The interceptor should be able to do anything it knows how > to do with the > > servant, except destroy it. > > Well, I guess we should say "shouldn't destroy it". Being pedantic, > I > doubt that we can stop that. Microsoft destroys internal > things all the time :)! Yes, you are right. The interceptor shouldn't do it unless it wants to cause the orb to crash. > So far, just me, because I'm trying to help out on the Domain > Management > RFP response so that interceptors can be used (but not > necessary) to get > what we want out of it, as we were discussing in Denver. The > secsig is now > copied on this. What about POA people? I believe you will find all the POA people who care via the orb_revision list. But the interceptors-ftf list is probably close enough. Paul Date: Wed, 22 Mar 2000 18:47:14 -0330 From: Matthew Newhook To: Harold Carr Cc: Paul Kyzivat , interceptors-ftf@omg.org Subject: Re: Using a POA (was: Interceptors and finalization, sorry for the tack-on) Message-ID: <20000322184714.A27896@ooc.com> References: <9B164B713EE9D211B6DC0090273CEEA926BD2C@bos1.noblenet.com> <38D93722.D9E1C86@sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <38D93722.D9E1C86@sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: $V[d9;=M!!bT$!!*FX!! Hi, On Wed, Mar 22, 2000 at 01:12:02PM -0800, Harold Carr wrote: > > > Paul Kyzivat wrote: > > > I suppose there could be a PortableServerRequestInfo interface > that > > derives from ServerRequestInfo and provides an accessor for the > POA. > > Then the interceptor would need to narrow the argument to get the > POA. > > Why have a derived interface? Why not just put in in > ServerRequestInfo? To keep the POA out of the ServerRequestInfo interface... > Would it be possible to define a base ObjectAdapter interface > and retrofit the POA to derive from it? Mmmm... perhaps this is possible. We did discuss this at one point if I remember. > H 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: Thu, 23 Mar 2000 09:16:59 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interceptors-ftf@omg.org Subject: RE: Using a POA (was: Interceptors and finalization, sorry for t he tack-on) In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BD30@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: HFg!!c_M!!Tj0e9BS@!! On Wed, 22 Mar 2000, Paul Kyzivat wrote: > > Why have a derived interface? Why not just put in in > > ServerRequestInfo? > > That would be fine with me. I have been repeatedly been making the > point > that we only standardize one adapter type (POA) and provide nothing > in the > way of a framework that would suggest how to introduce other > types. In that > context it seems pointless to make provisions for other sorts of > adapters. > > But it seems that people have been attempting to do just that, and I > am > trying to go along. This is a way to separate the POA specific > features from > the features that pertain to some abstract adapter. Keep in mind that it is at least possible that the multicast RFP will define a new adapter type. It would be nice if interceptors could work with multicast... > > Would it be possible to define a base ObjectAdapter interface > > and retrofit the POA to derive from it? I think that's possible, given that POAs are locality constrained. > I suppose we could consider that. But what capabilities would it have? Maybe only the most basic ones that would have to apply to all adapters, such name. I haven't thought about this yet... 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, 23 Mar 2000 16:39:45 +1000 (EST) From: Michi Henning To: Polar Humenn cc: Paul Kyzivat , interceptors-ftf@omg.org Subject: Re: Using a POA (was: Interceptors and finalization, sorry for the tack-on) In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: R!,!!g%`d9PT\!!'~;e9 On Wed, 22 Mar 2000, Polar Humenn wrote: > > > Is it proper to call on the located Servant in the interceptor? > > > > > > An interceptor may have intimate knowledge of the Servant > > > implemenation > > > and base access control on its contents, such as an account > > > number, etc. > > > Would this be allowed with the current architecture. I hope > > > so. If not, > > > what must we do? > > > > I think this is undefined currently, and must be discussed. > > Okay. That needs to be discussed. How do we start? > Anybody like to chime in? See my other post. Matthew, can you help out on that one? As far as I can see, there shouldn't be a problem with calling the servant from the interceptor because, for the interceptor to be able to see the request arguments, the servant must have been located already. 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, 23 Mar 2000 16:45:09 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interceptors-ftf@omg.org Subject: RE: Using a POA (was: Interceptors and finalization, sorry for t he tack-on) In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BD2C@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: /HVd9+@Z!!=DU!!aN[d9 On Wed, 22 Mar 2000, Paul Kyzivat wrote: > But I agree with you - there should be a way to access the POA itself. > At the moment I don't see any way to do that and retain opacity about > whether a POA, BOA, or something else is used. It's not all that elegant. Calling get_POA() would work, *if* the interceptor knows that POAs are used and *if* the adapter_id can be portably turned into a POA name. > > Okay, so is_to_servant(object_id) doesn't work if we must > > call a servant manager. What's the work around? > > The only work around I can see is for the interceptor to provide > access to the Servant. This suffers from some of the same problems > (and solutions) as access to the POA. > It has an added problem in that it will require some operation that returns > a Servant. That may present some technical problems. Why can't the interceptor not use id_to_servant()? 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, 23 Mar 2000 10:46:24 -0500 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Harold Carr CC: Paul Kyzivat , interceptors-ftf@omg.org Subject: Re: Using a POA (was: Interceptors and finalization, sorry for the tack-on) References: <9B164B713EE9D211B6DC0090273CEEA926BD2C@bos1.noblenet.com> <38D93722.D9E1C86@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: CE:!!p8+e9CPAe9# > Paul Kyzivat wrote: > > > I suppose there could be a PortableServerRequestInfo interface > that > > derives from ServerRequestInfo and provides an accessor for the > POA. > > Then the interceptor would need to narrow the argument to get the > POA. > > Why have a derived interface? Why not just put in in > ServerRequestInfo? Its been a goal to keep the PI interfaces OA-independent. > > Would it be possible to define a base ObjectAdapter interface > and retrofit the POA to derive from it? The notion of "ObjectAdapter" used in the POA (i.e. indidual instances of the POA interface) may not map to an equivalent notion in other OAs. Maybe you are looking for a more generic concept, such as endpoint? > > H -Bob From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Using a POA (was: Interceptors and finalization, sorry for t he tack-on) Date: Thu, 23 Mar 2000 13:21:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: /#,!!bS&!!@[hd9-9~e9 Bob, I think this makes sense for stuff that is very interceptor-related and not interesting in any other context. Otherwise, if we believe OMG needs to acknowledge the possibility of other object adapters then I think we ought to consider introducing some common base interface for all object adapters. I don't especially like making RequestInfo into a facade for everything that anybody might possibly want access to. Paul > From: Bob Kukura [mailto:kukura@iona.com] > There are ORBs that support multiple object adapters. > Anything done in > interceptors in a POA-specific way may end up being portable, but > may > also end up being useless on some ORBs when other OAs are in use. > The > goal should be to avoid the need for interceptors to be > OA-specific. > Instead, why not try to make whatever info the interceptor needs > from > the OA available in a more generic way, such as via a policy? Date: Thu, 23 Mar 2000 16:56:15 -0500 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: interceptors-ftf@omg.org Subject: Re: Using a POA (was: Interceptors and finalization, sorry for the tack-on) References: <9B164B713EE9D211B6DC0090273CEEA926BD42@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: #FKe9?k5e9N@od9Ud1!! Paul Kyzivat wrote: > > Bob, > > I think this makes sense for stuff that is very interceptor-related > and not > interesting in any other context. > > Otherwise, if we believe OMG needs to acknowledge the possibility of > other > object adapters then I think we ought to consider introducing some > common > base interface for all object adapters. I think the OMG has acknowledged the possibility of other object adapters since CORBA 1.0 and the original OMA. To me, the term "object adapter" refers to a specification of an API. The "Portable Object Adapter" happens to include an interface called "POA" in its API. But I don't see any obvious one-to-one correspondance between the interface called POA and the generic notion of an "object adapter". The POA interface could have been called something like PortableServer::GroupOfObjectsWithTheSamePoliciesAndActivators, and then I don't think we would be arguing it should have a base in common with other object adapters. I think the openness of CORBA to the possibility of other object adapters would be less valuable if we added a constraint that all object adapters had to include in their APIs some interface derived from some specific core interface. The role that interface plays in the POA might not even exist in some other kind of object adatpter. Some object adapters might not even have APIs expressed in CORBA IDL. > > I don't especially like making RequestInfo into a facade for > everything that > anybody might possibly want access to. I don't either. I'd rather find ways to do what needs to be done in portable interceptors without requiring those interceptors to know what kind of object adapter implements the object. Policies can go a long way here. If we really do have the requirement to get to POA specifics, then I've suggested in the past that RequestInfo could have an accessor that returns an object that can be narrowed to an object adapter specific interface, and the POA could include such an interface in its API. Actually, this interface could probably be a Policy, and therefore be accessible using the existing RequestInfo interface. -Bob > > Paul > > > From: Bob Kukura [mailto:kukura@iona.com] > > > There are ORBs that support multiple object adapters. > > Anything done in > > interceptors in a POA-specific way may end up being portable, but > may > > also end up being useless on some ORBs when other OAs are in use. > The > > goal should be to avoid the need for interceptors to be > OA-specific. > > Instead, why not try to make whatever info the interceptor needs > from > > the OA available in a more generic way, such as via a policy? From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Using a POA (was: Interceptors and finalization, sorry for t he tack-on) Date: Thu, 23 Mar 2000 17:35:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: h:dd9;#j!!Bd;e9Nm From: Bob Kukura [mailto:kukura@iona.com] > I think the OMG has acknowledged the possibility of other object > adapters since CORBA 1.0 and the original OMA. > > To me, the term "object adapter" refers to a specification of an > API. > The "Portable Object Adapter" happens to include an interface called > "POA" in its API. But I don't see any obvious one-to-one > correspondance > between the interface called POA and the generic notion of an > "object > adapter". The POA interface could have been called something like > PortableServer::GroupOfObjectsWithTheSamePoliciesAndActivators > , and then > I don't think we would be arguing it should have a base in common > with > other object adapters. Well, once upon a time the spec mentioned both BOA and LOA as object adapters (though I think LOA was only a hypothetical example). These were then removed, and replaced with POA. So it seems to me that POA is at least as much an example of an object adapter as any other. Otherwise we have a term with no concrete examples at all. Perhaps thats the case, but I hope not. > > I think the openness of CORBA to the possibility of other object > adapters would be less valuable if we added a constraint that > all object > adapters had to include in their APIs some interface derived from > some > specific core interface. The role that interface plays in > the POA might > not even exist in some other kind of object adatpter. Some object > adapters might not even have APIs expressed in CORBA IDL. > > > > > I don't especially like making RequestInfo into a facade > for everything that > > anybody might possibly want access to. > > I don't either. I'd rather find ways to do what needs to be done in > portable interceptors without requiring those interceptors to > know what > kind of object adapter implements the object. Policies can go a > long > way here. I don't see how policies help. To create policies and install them on something meaningful, I think you end up making the interceptor code specific to a particular kind of object adapter. Maybe this won't be the case for some simple situations, but it probably will be for anything complex. The thing that is pushing this right now is security. They need something to hook the notions of domain membership onto. There doesn't seem to be anything useful for that than POAs, unless they want all objects in the server to belong to a single domain. > > If we really do have the requirement to get to POA specifics, > then I've > suggested in the past that RequestInfo could have an accessor that > returns an object that can be narrowed to an object adapter specific > interface, and the POA could include such an interface in its API. > Actually, this interface could probably be a Policy, and therefore > be > accessible using the existing RequestInfo interface. That isn't much different than allowing the RequestInfo itself to be narrowed - saves an otherwise worthless object. Having said all that, I do have an open mind for some clean, general way to do this. But I would hate to see a lot of effort and added complexity in order to provide for some hypothetical other kind of object adapter that most likely doesn't and may never exist. Concrete examples (even if proprietary) would help make a case. Date: Fri, 24 Mar 2000 09:27:06 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interceptors-ftf@omg.org Subject: RE: Using a POA (was: Interceptors and finalization, sorry for t he tack-on) In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BD46@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Z2=!!K!H!!,\-e98:k!! On Thu, 23 Mar 2000, Paul Kyzivat wrote: > Having said all that, I do have an open mind for some clean, general way to > do this. But I would hate to see a lot of effort and added complexity in > order to provide for some hypothetical other kind of object adapter that > most likely doesn't and may never exist. Concrete examples (even if > proprietary) would help make a case. There is at least the possibility that the Multicast RFP may introduce a new object adapter. (That's not a given, by any stretch, but possible.) 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: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Using a POA (was: Interceptors and finalization, sorry for t he tack-on) Date: Thu, 23 Mar 2000 19:28:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: *1=!!Qo]!!aA&!!';md9 > From: Michi Henning [mailto:michi@ooc.com.au] > There is at least the possibility that the Multicast RFP may introduce > a new object adapter. (That's not a given, by any stretch, > but possible.) That *may* be a good test case. I haven't looked closely at that. Has anyone (probably from Inprise) considered in general the way interceptors would interact with this? Would it be possible to build a security interceptor that could do something meaningful without knowing what kind of adapter it was dealing with and doing adapter specific stuff? My guess it that the adapter is going to need to know. Date: Tue, 25 Jul 2000 12:09:13 -0230 From: Matthew Newhook To: interceptors-ftf@omg.org Subject: issue 3435 Message-ID: <20000725120913.A28324@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us Content-Type: text/plain; charset=us-ascii X-UIDL: Q]Me9IF,!!0i!"!\>R!! Hi, Please see proposal. Any comments welcome. Proposal: See the issue archive for discussion. This proposal is to add a destroy() method on PortableInterceptor::ClientRequestInterceptor, PortableInterceptor::ServerRequestInterceptor, PortableInterceptor::IORInterceptor. The destroy() method is called upon ORB::destroy() once all outstanding requests are complete. Specifics: Add to 21.3.5: local interface ClientRequestInterceptor : Interceptor { //... void destroy(); }; Add to 21.3.6: 21.3.6.x destroy This method is called upon ORB destruction to allow the release of all resources associated with the interceptor. Add to 21.3.8: local interface ServerRequestInterceptor : Interceptor { //... void destroy(); }; Add to 21.3.9: 21.3.9.x destroy This method is called upon ORB destruction to allow the release of all resources associated with the interceptor. Add to 21.5.2: local interface IORInterceptor : Interceptor { //... void destroy(); }; Add 21.5.2.x destroy This method is called upon ORB destruction to allow the release of all resources associated with the interceptor. In section to 4.2.3.5: After paragraph: If destroy is called on an ORB that has not been shut down, it will start the shut down process and block until the ORB has shut down before it destroys the ORB. If an application calls destroy in a thread that is currently servicing an invocation, the BAD_INV_ORDER system exception will be raised with the OMG minor code 3, since blocking would result in a deadlock. Add: Once the shutdown process is complete the destroy() method will be called on all registered portable interceptors. -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 26 Jul 2000 12:22:07 -0230 From: Matthew Newhook To: interceptors-ftf@omg.org Subject: Re: issue 3435 Message-ID: <20000726122207.A5759@ooc.com> References: <20000725120913.A28324@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <20000725120913.A28324@ooc.com> Content-Type: text/plain; charset=us-ascii X-UIDL: ;'Me9MY2!!e",!!UXgd9 Hi, Ok, I think my proposal for this issue can be simplified. The idea is to add the destroy() method to the Interceptor base interface ;) Proposal: See the issue for discussion. This proposal is to add a destroy() method on PortableInterceptor::Interceptor. The destroy() method is called upon ORB::destroy() once all outstanding requests are complete. Specifics: Add to 21.2: module PortableInterceptor { local interface Interceptor { readonly attribute string name; void destroy(); }; }; Add a description of the destroy() operation. This method is called upon ORB destruction to allow the release of all resources associated with the interceptor. In section to 4.2.3.5: After paragraph: If destroy is called on an ORB that has not been shut down, it will start the shut down process and block until the ORB has shut down before it destroys the ORB. If an application calls destroy in a thread that is currently servicing an invocation, the BAD_INV_ORDER system exception will be raised with the OMG minor code 3, since blocking would result in a deadlock. Add: Once the shutdown process is complete the destroy() method will be called on all registered portable interceptors. Best Regards, Matthew On Tue, Jul 25, 2000 at 12:09:13PM -0230, Matthew Newhook wrote: > Hi, > > Please see proposal. Any comments welcome. > > Proposal: > > See the issue archive for discussion. This proposal is to add a > destroy() method on PortableInterceptor::ClientRequestInterceptor, > PortableInterceptor::ServerRequestInterceptor, > PortableInterceptor::IORInterceptor. The destroy() method is called upon > ORB::destroy() once all outstanding requests are complete. > > Specifics: > > Add to 21.3.5: > > local interface ClientRequestInterceptor : Interceptor > { > //... > void destroy(); > }; > > Add to 21.3.6: > > 21.3.6.x destroy > > This method is called upon ORB destruction to allow the release of > all resources associated with the interceptor. > > Add to 21.3.8: > > local interface ServerRequestInterceptor : Interceptor > { > //... > void destroy(); > }; > > Add to 21.3.9: > > 21.3.9.x destroy > > This method is called upon ORB destruction to allow the release of > all resources associated with the interceptor. > > Add to 21.5.2: > > local interface IORInterceptor : Interceptor { > //... > void destroy(); > }; > > Add 21.5.2.x destroy > > This method is called upon ORB destruction to allow the release of > all resources associated with the interceptor. > > In section to 4.2.3.5: > > After paragraph: > > If destroy is called on an ORB that has not been shut down, it will start > the shut down process and block until the ORB has shut down before it > destroys the ORB. If an application calls destroy in a thread that is > currently servicing an invocation, the BAD_INV_ORDER system exception > will be raised with the OMG minor code 3, since blocking would result > in a deadlock. > > Add: > > Once the shutdown process is complete the destroy() method will be > called on all registered portable interceptors. > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 26 Jul 2000 08:25:46 -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 3435 References: <20000725120913.A28324@ooc.com> <20000726122207.A5759@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 12Ae9a`:e9LGY!!dXUd9 What is th motivation for this? Is it needed to support security or transactions? H Matthew Newhook wrote: > > Hi, > > Ok, I think my proposal for this issue can be simplified. The idea is > to add the destroy() method to the Interceptor base interface ;) > > Proposal: > > See the issue for discussion. This proposal is to add a destroy() method > on PortableInterceptor::Interceptor. The destroy() method is called > upon ORB::destroy() once all outstanding requests are complete. > > Specifics: > > Add to 21.2: > > module PortableInterceptor { > > local interface Interceptor { > readonly attribute string name; > > void destroy(); > }; > > }; > > Add a description of the destroy() operation. > > This method is called upon ORB destruction to allow the release of > all resources associated with the interceptor. > > In section to 4.2.3.5: > > After paragraph: > > If destroy is called on an ORB that has not been shut down, it will start > the shut down process and block until the ORB has shut down before it > destroys the ORB. If an application calls destroy in a thread that is > currently servicing an invocation, the BAD_INV_ORDER system exception > will be raised with the OMG minor code 3, since blocking would result > in a deadlock. > > Add: > > Once the shutdown process is complete the destroy() method will be > called on all registered portable interceptors. > > Best Regards, Matthew > > On Tue, Jul 25, 2000 at 12:09:13PM -0230, Matthew Newhook wrote: > > Hi, > > > > Please see proposal. Any comments welcome. > > > > Proposal: > > > > See the issue archive for discussion. This proposal is to add a > > destroy() method on PortableInterceptor::ClientRequestInterceptor, > > PortableInterceptor::ServerRequestInterceptor, > > PortableInterceptor::IORInterceptor. The destroy() method is called upon > > ORB::destroy() once all outstanding requests are complete. > > > > Specifics: > > > > Add to 21.3.5: > > > > local interface ClientRequestInterceptor : Interceptor > > { > > //... > > void destroy(); > > }; > > > > Add to 21.3.6: > > > > 21.3.6.x destroy > > > > This method is called upon ORB destruction to allow the release of > > all resources associated with the interceptor. > > > > Add to 21.3.8: > > > > local interface ServerRequestInterceptor : Interceptor > > { > > //... > > void destroy(); > > }; > > > > Add to 21.3.9: > > > > 21.3.9.x destroy > > > > This method is called upon ORB destruction to allow the release of > > all resources associated with the interceptor. > > > > Add to 21.5.2: > > > > local interface IORInterceptor : Interceptor { > > //... > > void destroy(); > > }; > > > > Add 21.5.2.x destroy > > > > This method is called upon ORB destruction to allow the release of > > all resources associated with the interceptor. > > > > In section to 4.2.3.5: > > > > After paragraph: > > > > If destroy is called on an ORB that has not been shut down, it will start > > the shut down process and block until the ORB has shut down before it > > destroys the ORB. If an application calls destroy in a thread that is > > currently servicing an invocation, the BAD_INV_ORDER system exception > > will be raised with the OMG minor code 3, since blocking would result > > in a deadlock. > > > > Add: > > > > Once the shutdown process is complete the destroy() method will be > > called on all registered portable interceptors. > > -- > > Matthew Newhook E-Mail: mailto:matthew@ooc.com > > Software Designer WWW: http://www.ooc.com > > Object Oriented Concepts, Inc. Phone: (709) 738-3725 > > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 26 Jul 2000 09:31:47 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Matthew Newhook , interceptors-ftf@omg.org Subject: Re: issue 3435 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,,R!!W0N!!1>;!!',Ne9 Could one of you two please resubmit what you want included in the vote? Thanks, Harold Michi Henning wrote: > > On Wed, 26 Jul 2000, Matthew Newhook wrote: > > > In section to 4.2.3.5: > > That's section 4.11.5 now in the 2.3.1 spec. > > > Add: > > > > Once the shutdown process is complete the destroy() method will be > > called on all registered portable interceptors. > > I would rephrase to avoid passive speech and get an actor: > > Once the shutdown process is complete, ORB::destroy() calls > the Interceptor::destroy() operation on each registered portable > interceptor. > > 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, 26 Jul 2000 14:09:02 -0230 From: Matthew Newhook To: Harold Carr Cc: interceptors-ftf@omg.org Subject: Re: issue 3435 Message-ID: <20000726140902.A7684@ooc.com> References: <20000725120913.A28324@ooc.com> <20000726122207.A5759@ooc.com> <397F02FA.20159831@sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <397F02FA.20159831@sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: What is th motivation for this? > Is it needed to support security or transactions? I think that the original mail archive has all the necessary motivation for this. However, to recap -- basically the interceptors are not told in any standard way that the ORB is going away. Therefore if the interceptor has to do cleanup (such as close database resources), etc. then it cannot do this. Of course, some languages support ways to do this (such as C++ destructors) -- however, many do not (such as C, etc) > H 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: Wed, 26 Jul 2000 09:46:32 -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 3435 References: <20000725120913.A28324@ooc.com> <20000726122207.A5759@ooc.com> <397F02FA.20159831@sun.com> <20000726140902.A7684@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: iDX!!7`E!!J+\d9j@7!! Thanks for the recap. In your proposal you put destroy on the base Interceptor class. I would prefer that specific destroy interceptors be registered. H Matthew Newhook wrote: > > Hi, > > On Wed, Jul 26, 2000 at 08:25:46AM -0700, Harold Carr wrote: > > What is th motivation for this? > > Is it needed to support security or transactions? > > I think that the original mail archive has all the necessary motivation > for this. However, to recap -- basically the interceptors are not > told in any standard way that the ORB is going away. Therefore if the > interceptor has to do cleanup (such as close database resources), etc. > then it cannot do this. Of course, some languages support ways to do this > (such as C++ destructors) -- however, many do not (such as C, etc) > > > H > > 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: Wed, 26 Jul 2000 14:19:18 -0230 From: Matthew Newhook To: Harold Carr Cc: interceptors-ftf@omg.org Subject: Re: issue 3435 Message-ID: <20000726141918.E7684@ooc.com> References: <20000725120913.A28324@ooc.com> <20000726122207.A5759@ooc.com> <397F02FA.20159831@sun.com> <20000726140902.A7684@ooc.com> <397F15E8.FC8409E5@sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <397F15E8.FC8409E5@sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: 0b!"!lD3!![i/e9B]+e9 Hi Harold, On Wed, Jul 26, 2000 at 09:46:32AM -0700, Harold Carr wrote: > Thanks for the recap. In your proposal you put destroy on the base > Interceptor class. I would prefer that specific destroy interceptors be > registered. That was my original proposal. However, I think it's wrong because any interceptor will most likely need a standard way to be notified that the ORB is being destroyed. > H 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: Wed, 26 Jul 2000 14:40:34 -0230 From: Matthew Newhook To: Harold Carr Cc: Michi Henning , interceptors-ftf@omg.org Subject: Re: issue 3435 Message-ID: <20000726144034.A8367@ooc.com> References: <397F1273.5B78156A@sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <397F1273.5B78156A@sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: Bk>!!8'g!!i@jd912/e9 Hi, Proposal: See the issue for discussion. This proposal is to add a destroy() method on PortableInterceptor::Interceptor. The destroy() method is called upon ORB::destroy() once all outstanding requests are complete. Specifics: Add to 21.2: module PortableInterceptor { local interface Interceptor { readonly attribute string name; void destroy(); }; }; Add a description of the destroy() operation. This method is called upon ORB destruction to allow the release of all resources associated with the interceptor. In section to 4.2.3.5: After paragraph: If destroy is called on an ORB that has not been shut down, it will start the shut down process and block until the ORB has shut down before it destroys the ORB. If an application calls destroy in a thread that is currently servicing an invocation, the BAD_INV_ORDER system exception will be raised with the OMG minor code 3, since blocking would result in a deadlock. Add: Once the shutdown process is complete, ORB::destroy() calls the Interceptor::destroy() operation on each registered portable interceptor. Regards, Matthew On Wed, Jul 26, 2000 at 09:31:47AM -0700, Harold Carr wrote: > Could one of you two please resubmit what you want included in the vote? > > Thanks, > Harold > > > Michi Henning wrote: > > > > On Wed, 26 Jul 2000, Matthew Newhook wrote: > > > > > In section to 4.2.3.5: > > > > That's section 4.11.5 now in the 2.3.1 spec. > > > > > Add: > > > > > > Once the shutdown process is complete the destroy() method will be > > > called on all registered portable interceptors. > > > > I would rephrase to avoid passive speech and get an actor: > > > > Once the shutdown process is complete, ORB::destroy() calls > > the Interceptor::destroy() operation on each registered portable > > interceptor. > > > > 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 -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 26 Jul 2000 10:21:29 -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 3435 References: <20000725120913.A28324@ooc.com> <20000726122207.A5759@ooc.com> <397F02FA.20159831@sun.com> <20000726140902.A7684@ooc.com> <397F15E8.FC8409E5@sun.com> <20000726141918.E7684@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: PcO!!ZVDe94mc!!T > Hi Harold, > > On Wed, Jul 26, 2000 at 09:46:32AM -0700, Harold Carr wrote: > > Thanks for the recap. In your proposal you put destroy on the base > > Interceptor class. I would prefer that specific destroy interceptors be > > registered. > > That was my original proposal. However, I think it's wrong because any > interceptor will most likely need a standard way to be notified that the > ORB is being destroyed. > > > H > > 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: Wed, 26 Jul 2000 15:04:09 -0230 From: Matthew Newhook To: Harold Carr Cc: interceptors-ftf@omg.org Subject: Re: issue 3435 Message-ID: <20000726150408.A8529@ooc.com> References: <20000725120913.A28324@ooc.com> <20000726122207.A5759@ooc.com> <397F02FA.20159831@sun.com> <20000726140902.A7684@ooc.com> <397F15E8.FC8409E5@sun.com> <20000726141918.E7684@ooc.com> <397F1E19.83DB2AAC@sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <397F1E19.83DB2AAC@sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: #dk!!B^\!!pUJ!!C>@e9 Hi, On Wed, Jul 26, 2000 at 10:21:29AM -0700, Harold Carr wrote: > I prefer the "mixin" approach. If a ClientRequestInterceptor wants to > get a destroy notification, then the implementation of that interceptor > can derived from both ClientRequestInterceptor and ORBDestoryInterceptor > (or whatever you called it). Then it registers itself under both > categories. > > I do not like adding this to the base class at all. In other words, if > you want destroy notification, ask for it. So the ORB needs to call _is_a on the interceptors to determine to call destroy() on the interface? Personally I hate that. Didn't we have this discussion ad-infinitum in the original talks regarding the original interface design? ;) > H 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: Wed, 26 Jul 2000 10:38:27 -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 3435 References: <20000725120913.A28324@ooc.com> <20000726122207.A5759@ooc.com> <397F02FA.20159831@sun.com> <20000726140902.A7684@ooc.com> <397F15E8.FC8409E5@sun.com> <20000726141918.E7684@ooc.com> <397F1E19.83DB2AAC@sun.com> <20000726150408.A8529@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Q(J!!Zg4e9LXJ!!oh0!! That isn't what I said. I said the implementation derives from both request and destroy interceptors and then registers itself twice - once as a destroy interceptor, and then again as a request interceptor. No is_a involved. H Matthew Newhook wrote: > > Hi, > > On Wed, Jul 26, 2000 at 10:21:29AM -0700, Harold Carr wrote: > > I prefer the "mixin" approach. If a ClientRequestInterceptor wants to > > get a destroy notification, then the implementation of that interceptor > > can derived from both ClientRequestInterceptor and ORBDestoryInterceptor > > (or whatever you called it). Then it registers itself under both > > categories. > > > > I do not like adding this to the base class at all. In other words, if > > you want destroy notification, ask for it. > > So the ORB needs to call _is_a on the interceptors to determine to call > destroy() on the interface? Personally I hate that. > > Didn't we have this discussion ad-infinitum in the original talks > regarding the original interface design? ;) > > > H > > 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: Wed, 26 Jul 2000 15:15:34 -0230 From: Matthew Newhook To: Harold Carr Cc: interceptors-ftf@omg.org Subject: Re: issue 3435 Message-ID: <20000726151534.A8588@ooc.com> References: <20000725120913.A28324@ooc.com> <20000726122207.A5759@ooc.com> <397F02FA.20159831@sun.com> <20000726140902.A7684@ooc.com> <397F15E8.FC8409E5@sun.com> <20000726141918.E7684@ooc.com> <397F1E19.83DB2AAC@sun.com> <20000726150408.A8529@ooc.com> <397F2213.2706F87D@sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <397F2213.2706F87D@sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: 1cK!!'k7!!e[Le9KiLe9 Hi, On Wed, Jul 26, 2000 at 10:38:27AM -0700, Harold Carr wrote: > That isn't what I said. I said the implementation derives from both > request and destroy interceptors and then registers itself twice - once > as a destroy interceptor, and then again as a request interceptor. No > is_a involved. Ok, I understand now. I still don't like it. If you want to go ahead with that I suggest writing up a proposal and adding it to the ballot as a choice. The votes would be NO, choice A, choice B. > H 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 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 26 Jul 2000 14:12:44 -0400 (EDT) From: Polar Humenn To: Matthew Newhook cc: Harold Carr , interceptors-ftf@omg.org Subject: Re: issue 3435 In-Reply-To: <20000726140902.A7684@ooc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: khp!!8<6e9-CAe9]B#"! On Wed, 26 Jul 2000, Matthew Newhook wrote: > Hi, > > On Wed, Jul 26, 2000 at 08:25:46AM -0700, Harold Carr wrote: > > What is th motivation for this? > > Is it needed to support security or transactions? > > I think that the original mail archive has all the necessary > motivation > for this. However, to recap -- basically the interceptors are not > told in any standard way that the ORB is going away. Therefore if > the > interceptor has to do cleanup (such as close database resources), > etc. > then it cannot do this. Of course, some languages support ways to do > this > (such as C++ destructors) -- however, many do not (such as C, etc) Also, for security, it is possible for some security mechanisms to take advantge of existing security mechanisms by storing temporary credentials in files, i.e. a Kerberos Credentials Cache. They would need to be disposed of properly when the ORB shutsdown. > > > H > > 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 > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Wed, 26 Jul 2000 11:20:41 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Matthew Newhook , Michi Henning , interceptors-ftf@omg.org Subject: Re: issue 3435 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: f:1e9H3Le9Dgf!!];De9 I agree it should be prohibited - but I do not agree about an exception. Who would catch the exception? The spec should just say calls are not allowed. It should probably say that results are undefined if calls are attempted. Matthew, if you agree along these lines, could you update your proposal? H Polar Humenn wrote: > > What happens if the interceptor needs to do CORBA calls while shutting > down, i.e. during "destroy()"? > > I imagine that this kind of thing should be prohibited? > If so, it should be explicitly stated with an exception? > > Just asking. :) > -Polar > > On Wed, 26 Jul 2000, Matthew Newhook wrote: > > > Hi, > > > > Proposal: > > > > See the issue for discussion. This proposal is to add a destroy() method > > on PortableInterceptor::Interceptor. The destroy() method is called > > upon ORB::destroy() once all outstanding requests are complete. > > > > Specifics: > > > > Add to 21.2: > > > > module PortableInterceptor { > > > > local interface Interceptor { > > readonly attribute string name; > > > > void destroy(); > > }; > > > > }; > > > > Add a description of the destroy() operation. > > > > This method is called upon ORB destruction to allow the release of > > all resources associated with the interceptor. > > > > In section to 4.2.3.5: > > > > After paragraph: > > > > If destroy is called on an ORB that has not been shut down, it will start > > the shut down process and block until the ORB has shut down before it > > destroys the ORB. If an application calls destroy in a thread that is > > currently servicing an invocation, the BAD_INV_ORDER system exception > > will be raised with the OMG minor code 3, since blocking would result > > in a deadlock. > > > > Add: > > > > Once the shutdown process is complete, ORB::destroy() calls the > > Interceptor::destroy() operation on each registered portable > > interceptor. > > > > Regards, Matthew > > > > On Wed, Jul 26, 2000 at 09:31:47AM -0700, Harold Carr wrote: > > > Could one of you two please resubmit what you want included in the vote? > > > > > > Thanks, > > > Harold > > > > > > > > > Michi Henning wrote: > > > > > > > > On Wed, 26 Jul 2000, Matthew Newhook wrote: > > > > > > > > > In section to 4.2.3.5: > > > > > > > > That's section 4.11.5 now in the 2.3.1 spec. > > > > > > > > > Add: > > > > > > > > > > Once the shutdown process is complete the destroy() method will be > > > > > called on all registered portable interceptors. > > > > > > > > I would rephrase to avoid passive speech and get an actor: > > > > > > > > Once the shutdown process is complete, ORB::destroy() calls > > > > the Interceptor::destroy() operation on each registered portable > > > > interceptor. > > > > > > > > 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 > > > > -- > > Matthew Newhook E-Mail: mailto:matthew@ooc.com > > Software Designer WWW: http://www.ooc.com > > Object Oriented Concepts, Inc. Phone: (709) 738-3725 > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 26 Jul 2000 14:18:23 -0400 (EDT) From: Polar Humenn To: Matthew Newhook cc: Harold Carr , Michi Henning , interceptors-ftf@omg.org Subject: Re: issue 3435 In-Reply-To: <20000726144034.A8367@ooc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: UB:e9eS6e9W%9e9h>jd9 What happens if the interceptor needs to do CORBA calls while shutting down, i.e. during "destroy()"? I imagine that this kind of thing should be prohibited? If so, it should be explicitly stated with an exception? Just asking. :) -Polar On Wed, 26 Jul 2000, Matthew Newhook wrote: > Hi, > > Proposal: > > See the issue for discussion. This proposal is to add a destroy() > method > on PortableInterceptor::Interceptor. The destroy() method is called > upon ORB::destroy() once all outstanding requests are complete. > > Specifics: > > Add to 21.2: > > module PortableInterceptor { > > local interface Interceptor { > readonly attribute string name; > > void destroy(); > }; > > }; > > Add a description of the destroy() operation. > > This method is called upon ORB destruction to allow the release > of > all resources associated with the interceptor. > > In section to 4.2.3.5: > > After paragraph: > > If destroy is called on an ORB that has not been shut down, it > will start > the shut down process and block until the ORB has shut down before > it > destroys the ORB. If an application calls destroy in a thread that > is > currently servicing an invocation, the BAD_INV_ORDER system > exception > will be raised with the OMG minor code 3, since blocking would > result > in a deadlock. > > Add: > > Once the shutdown process is complete, ORB::destroy() calls the > Interceptor::destroy() operation on each registered portable > interceptor. > > Regards, Matthew > > On Wed, Jul 26, 2000 at 09:31:47AM -0700, Harold Carr wrote: > > Could one of you two please resubmit what you want included in the > vote? > > > > Thanks, > > Harold > > > > > > Michi Henning wrote: > > > > > > On Wed, 26 Jul 2000, Matthew Newhook wrote: > > > > > > > In section to 4.2.3.5: > > > > > > That's section 4.11.5 now in the 2.3.1 spec. > > > > > > > Add: > > > > > > > > Once the shutdown process is complete the destroy() method > will be > > > > called on all registered portable interceptors. > > > > > > I would rephrase to avoid passive speech and get an actor: > > > > > > Once the shutdown process is complete, ORB::destroy() > calls > > > the Interceptor::destroy() operation on each registered > portable > > > interceptor. > > > > > > 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 > > -- > Matthew Newhook E-Mail: > mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 26 Jul 2000 14:36:35 -0400 (EDT) From: Polar Humenn To: Harold Carr cc: Matthew Newhook , Michi Henning , interceptors-ftf@omg.org Subject: Re: issue 3435 In-Reply-To: <397F2BF9.9D7CB7C3@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ;VTd9U!&e9=_7!!5GU!! On Wed, 26 Jul 2000, Harold Carr wrote: > I agree it should be prohibited - but I do not agree about an > exception. Who would catch the exception? The spec should just say > calls are not allowed. It should probably say that results are > undefined if calls are attempted. Great way to crash a system. Microsoft approach. How about the interceptor call is considered over and the next destroy call is processed? -Polar > > Matthew, if you agree along these lines, could you update your > proposal? > > H > > > Polar Humenn wrote: > > > > What happens if the interceptor needs to do CORBA calls while > shutting > > down, i.e. during "destroy()"? > > > > I imagine that this kind of thing should be prohibited? > > If so, it should be explicitly stated with an exception? > > > > Just asking. :) > > -Polar > > > > On Wed, 26 Jul 2000, Matthew Newhook wrote: > > > > > Hi, > > > > > > Proposal: > > > > > > See the issue for discussion. This proposal is to add a > destroy() method > > > on PortableInterceptor::Interceptor. The destroy() method is > called > > > upon ORB::destroy() once all outstanding requests are complete. > > > > > > Specifics: > > > > > > Add to 21.2: > > > > > > module PortableInterceptor { > > > > > > local interface Interceptor { > > > readonly attribute string name; > > > > > > void destroy(); > > > }; > > > > > > }; > > > > > > Add a description of the destroy() operation. > > > > > > This method is called upon ORB destruction to allow the > release of > > > all resources associated with the interceptor. > > > > > > In section to 4.2.3.5: > > > > > > After paragraph: > > > > > > If destroy is called on an ORB that has not been shut down, it > will start > > > the shut down process and block until the ORB has shut down > before it > > > destroys the ORB. If an application calls destroy in a thread > that is > > > currently servicing an invocation, the BAD_INV_ORDER system > exception > > > will be raised with the OMG minor code 3, since blocking would > result > > > in a deadlock. > > > > > > Add: > > > > > > Once the shutdown process is complete, ORB::destroy() calls > the > > > Interceptor::destroy() operation on each registered portable > > > interceptor. > > > > > > Regards, Matthew > > > > > > On Wed, Jul 26, 2000 at 09:31:47AM -0700, Harold Carr wrote: > > > > Could one of you two please resubmit what you want included in > the vote? > > > > > > > > Thanks, > > > > Harold > > > > > > > > > > > > Michi Henning wrote: > > > > > > > > > > On Wed, 26 Jul 2000, Matthew Newhook wrote: > > > > > > > > > > > In section to 4.2.3.5: > > > > > > > > > > That's section 4.11.5 now in the 2.3.1 spec. > > > > > > > > > > > Add: > > > > > > > > > > > > Once the shutdown process is complete the destroy() > method will be > > > > > > called on all registered portable interceptors. > > > > > > > > > > I would rephrase to avoid passive speech and get an actor: > > > > > > > > > > Once the shutdown process is complete, > ORB::destroy() calls > > > > > the Interceptor::destroy() operation on each > registered portable > > > > > interceptor. > > > > > > > > > > > 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 > > > > > > -- > > > Matthew Newhook E-Mail: > mailto:matthew@ooc.com > > > Software Designer WWW: > http://www.ooc.com > > > Object Oriented Concepts, Inc. Phone: (709) 738-3725 > > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Wed, 26 Jul 2000 11:44:56 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Matthew Newhook , Michi Henning , interceptors-ftf@omg.org Subject: Re: issue 3435 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: KKb!!iOWd9R<~e9~WFe9 What does the CORBA 2.3 (or whatever) spec say about calls on an ORB that is destroyed? We should considered that the ORB is essentially destroyed when this interceptor is called so we are in the same situation. I do not think you can say "just call the next - that constrains ORB implementations too much... H Polar Humenn wrote: > > On Wed, 26 Jul 2000, Harold Carr wrote: > > > I agree it should be prohibited - but I do not agree about an > > exception. Who would catch the exception? The spec should just say > > calls are not allowed. It should probably say that results are > > undefined if calls are attempted. > > Great way to crash a system. Microsoft approach. > > How about the interceptor call is considered over and the next destroy > call is processed? > > -Polar > > > > > Matthew, if you agree along these lines, could you update your proposal? > > > > H > > > > > > Polar Humenn wrote: > > > > > > What happens if the interceptor needs to do CORBA calls while shutting > > > down, i.e. during "destroy()"? > > > > > > I imagine that this kind of thing should be prohibited? > > > If so, it should be explicitly stated with an exception? > > > > > > Just asking. :) > > > -Polar > > > > > > On Wed, 26 Jul 2000, Matthew Newhook wrote: > > > > > > > Hi, > > > > > > > > Proposal: > > > > > > > > See the issue for discussion. This proposal is to add a destroy() method > > > > on PortableInterceptor::Interceptor. The destroy() method is called > > > > upon ORB::destroy() once all outstanding requests are complete. > > > > > > > > Specifics: > > > > > > > > Add to 21.2: > > > > > > > > module PortableInterceptor { > > > > > > > > local interface Interceptor { > > > > readonly attribute string name; > > > > > > > > void destroy(); > > > > }; > > > > > > > > }; > > > > > > > > Add a description of the destroy() operation. > > > > > > > > This method is called upon ORB destruction to allow the release of > > > > all resources associated with the interceptor. > > > > > > > > In section to 4.2.3.5: > > > > > > > > After paragraph: > > > > > > > > If destroy is called on an ORB that has not been shut down, it will start > > > > the shut down process and block until the ORB has shut down before it > > > > destroys the ORB. If an application calls destroy in a thread that is > > > > currently servicing an invocation, the BAD_INV_ORDER system exception > > > > will be raised with the OMG minor code 3, since blocking would result > > > > in a deadlock. > > > > > > > > Add: > > > > > > > > Once the shutdown process is complete, ORB::destroy() calls the > > > > Interceptor::destroy() operation on each registered portable > > > > interceptor. > > > > > > > > Regards, Matthew > > > > > > > > On Wed, Jul 26, 2000 at 09:31:47AM -0700, Harold Carr wrote: > > > > > Could one of you two please resubmit what you want included in the vote? > > > > > > > > > > Thanks, > > > > > Harold > > > > > > > > > > > > > > > Michi Henning wrote: > > > > > > > > > > > > On Wed, 26 Jul 2000, Matthew Newhook wrote: > > > > > > > > > > > > > In section to 4.2.3.5: > > > > > > > > > > > > That's section 4.11.5 now in the 2.3.1 spec. > > > > > > > > > > > > > Add: > > > > > > > > > > > > > > Once the shutdown process is complete the destroy() method will be > > > > > > > called on all registered portable interceptors. > > > > > > > > > > > > I would rephrase to avoid passive speech and get an actor: > > > > > > > > > > > > Once the shutdown process is complete, ORB::destroy() calls > > > > > > the Interceptor::destroy() operation on each registered portable > > > > > > interceptor. > > > > > > > > > > > > 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 > > > > > > > > -- > > > > Matthew Newhook E-Mail: mailto:matthew@ooc.com > > > > Software Designer WWW: http://www.ooc.com > > > > Object Oriented Concepts, Inc. Phone: (709) 738-3725 > > > > > > > > > > ------------------------------------------------------------------- > > > Polar Humenn Adiron, LLC > > > mailto:polar@adiron.com 2-212 CST > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > Fax: 315-443-4745 http://www.adiron.com > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com Date: Wed, 26 Jul 2000 15:58:28 -0230 From: Matthew Newhook To: Harold Carr Cc: Polar Humenn , Michi Henning , interceptors-ftf@omg.org Subject: Re: issue 3435 Message-ID: <20000726155828.A9277@ooc.com> References: <397F2BF9.9D7CB7C3@sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <397F2BF9.9D7CB7C3@sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: 4H=e9-P,e9$7>!!QJR!! Hi, The difference is the new text in the description of destroy(). Proposal: See the issue for discussion. This proposal is to add a destroy() method on PortableInterceptor::Interceptor. The destroy() method is called upon ORB::destroy() once all outstanding requests are complete. Specifics: Add to 21.2: module PortableInterceptor { local interface Interceptor { readonly attribute string name; void destroy(); }; }; Add a description of the destroy() operation. This method is called upon ORB destruction to allow the release of all resources associated with the interceptor. Method invocations on object-references belonging to the ORB being destroyed are not permitted and shall result in undefined behaviour. In section to 4.2.3.5: After paragraph: If destroy is called on an ORB that has not been shut down, it will start the shut down process and block until the ORB has shut down before it destroys the ORB. If an application calls destroy in a thread that is currently servicing an invocation, the BAD_INV_ORDER system exception will be raised with the OMG minor code 3, since blocking would result in a deadlock. Add: Once the shutdown process is complete, ORB::destroy() calls the Interceptor::destroy() operation on each registered portable interceptor. On Wed, Jul 26, 2000 at 11:20:41AM -0700, Harold Carr wrote: > I agree it should be prohibited - but I do not agree about an > exception. Who would catch the exception? The spec should just say > calls are not allowed. It should probably say that results are > undefined if calls are attempted. > > Matthew, if you agree along these lines, could you update your proposal? > > H > > > Polar Humenn wrote: > > > > What happens if the interceptor needs to do CORBA calls while shutting > > down, i.e. during "destroy()"? > > > > I imagine that this kind of thing should be prohibited? > > If so, it should be explicitly stated with an exception? > > > > Just asking. :) > > -Polar > > > > On Wed, 26 Jul 2000, Matthew Newhook wrote: > > > > > Hi, > > > > > > Proposal: > > > > > > See the issue for discussion. This proposal is to add a destroy() method > > > on PortableInterceptor::Interceptor. The destroy() method is called > > > upon ORB::destroy() once all outstanding requests are complete. > > > > > > Specifics: > > > > > > Add to 21.2: > > > > > > module PortableInterceptor { > > > > > > local interface Interceptor { > > > readonly attribute string name; > > > > > > void destroy(); > > > }; > > > > > > }; > > > > > > Add a description of the destroy() operation. > > > > > > This method is called upon ORB destruction to allow the release of > > > all resources associated with the interceptor. > > > > > > In section to 4.2.3.5: > > > > > > After paragraph: > > > > > > If destroy is called on an ORB that has not been shut down, it will start > > > the shut down process and block until the ORB has shut down before it > > > destroys the ORB. If an application calls destroy in a thread that is > > > currently servicing an invocation, the BAD_INV_ORDER system exception > > > will be raised with the OMG minor code 3, since blocking would result > > > in a deadlock. > > > > > > Add: > > > > > > Once the shutdown process is complete, ORB::destroy() calls the > > > Interceptor::destroy() operation on each registered portable > > > interceptor. > > > > > > Regards, Matthew > > > > > > On Wed, Jul 26, 2000 at 09:31:47AM -0700, Harold Carr wrote: > > > > Could one of you two please resubmit what you want included in the vote? > > > > > > > > Thanks, > > > > Harold > > > > > > > > > > > > Michi Henning wrote: > > > > > > > > > > On Wed, 26 Jul 2000, Matthew Newhook wrote: > > > > > > > > > > > In section to 4.2.3.5: > > > > > > > > > > That's section 4.11.5 now in the 2.3.1 spec. > > > > > > > > > > > Add: > > > > > > > > > > > > Once the shutdown process is complete the destroy() method will be > > > > > > called on all registered portable interceptors. > > > > > > > > > > I would rephrase to avoid passive speech and get an actor: > > > > > > > > > > Once the shutdown process is complete, ORB::destroy() calls > > > > > the Interceptor::destroy() operation on each registered portable > > > > > interceptor. > > > > > > > > > > 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 > > > > > > -- > > > Matthew Newhook E-Mail: mailto:matthew@ooc.com > > > Software Designer WWW: http://www.ooc.com > > > Object Oriented Concepts, Inc. Phone: (709) 738-3725 > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 26 Jul 2000 14:57:48 -0400 From: Matthew Mihic Organization: IONA Technologies, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Harold Carr , Matthew Newhook , Michi Henning , interceptors-ftf@omg.org Subject: Re: issue 3435 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 3c1!!YnN!!ci[!!1>]!! The spec already says that invoking on an object reference after the ORB has shutdown will result in a BAD_INV_ORDER exception, so I don't think we need any special language covering this case in the Portable Interceptor spec. I'd prefer to simply say that an exceptions raised by the Interceptor::destroy() operation are caught by the ORB and ignored. Regards, Matt Polar Humenn wrote: > > On Wed, 26 Jul 2000, Harold Carr wrote: > > > I agree it should be prohibited - but I do not agree about an > > exception. Who would catch the exception? The spec should just say > > calls are not allowed. It should probably say that results are > > undefined if calls are attempted. > > Great way to crash a system. Microsoft approach. > > How about the interceptor call is considered over and the next destroy > call is processed? > > -Polar > > > > > Matthew, if you agree along these lines, could you update your proposal? > > > > H > > > > > > Polar Humenn wrote: > > > > > > What happens if the interceptor needs to do CORBA calls while shutting > > > down, i.e. during "destroy()"? > > > > > > I imagine that this kind of thing should be prohibited? > > > If so, it should be explicitly stated with an exception? > > > > > > Just asking. :) > > > -Polar > > > > > > On Wed, 26 Jul 2000, Matthew Newhook wrote: > > > > > > > Hi, > > > > > > > > Proposal: > > > > > > > > See the issue for discussion. This proposal is to add a destroy() method > > > > on PortableInterceptor::Interceptor. The destroy() method is called > > > > upon ORB::destroy() once all outstanding requests are complete. > > > > > > > > Specifics: > > > > > > > > Add to 21.2: > > > > > > > > module PortableInterceptor { > > > > > > > > local interface Interceptor { > > > > readonly attribute string name; > > > > > > > > void destroy(); > > > > }; > > > > > > > > }; > > > > > > > > Add a description of the destroy() operation. > > > > > > > > This method is called upon ORB destruction to allow the release of > > > > all resources associated with the interceptor. > > > > > > > > In section to 4.2.3.5: > > > > > > > > After paragraph: > > > > > > > > If destroy is called on an ORB that has not been shut down, it will start > > > > the shut down process and block until the ORB has shut down before it > > > > destroys the ORB. If an application calls destroy in a thread that is > > > > currently servicing an invocation, the BAD_INV_ORDER system exception > > > > will be raised with the OMG minor code 3, since blocking would result > > > > in a deadlock. > > > > > > > > Add: > > > > > > > > Once the shutdown process is complete, ORB::destroy() calls the > > > > Interceptor::destroy() operation on each registered portable > > > > interceptor. > > > > > > > > Regards, Matthew > > > > > > > > On Wed, Jul 26, 2000 at 09:31:47AM -0700, Harold Carr wrote: > > > > > Could one of you two please resubmit what you want included in the vote? > > > > > > > > > > Thanks, > > > > > Harold > > > > > > > > > > > > > > > Michi Henning wrote: > > > > > > > > > > > > On Wed, 26 Jul 2000, Matthew Newhook wrote: > > > > > > > > > > > > > In section to 4.2.3.5: > > > > > > > > > > > > That's section 4.11.5 now in the 2.3.1 spec. > > > > > > > > > > > > > Add: > > > > > > > > > > > > > > Once the shutdown process is complete the destroy() method will be > > > > > > > called on all registered portable interceptors. > > > > > > > > > > > > I would rephrase to avoid passive speech and get an actor: > > > > > > > > > > > > Once the shutdown process is complete, ORB::destroy() calls > > > > > > the Interceptor::destroy() operation on each registered portable > > > > > > interceptor. > > > > > > > > > > > > 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 > > > > > > > > -- > > > > Matthew Newhook E-Mail: mailto:matthew@ooc.com > > > > Software Designer WWW: http://www.ooc.com > > > > Object Oriented Concepts, Inc. Phone: (709) 738-3725 > > > > > > > > > > ------------------------------------------------------------------- > > > Polar Humenn Adiron, LLC > > > mailto:polar@adiron.com 2-212 CST > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > Fax: 315-443-4745 http://www.adiron.com > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 26 Jul 2000 15:54:37 -0400 (EDT) From: Polar Humenn To: Harold Carr cc: Matthew Newhook , Michi Henning , interceptors-ftf@omg.org Subject: Re: issue 3435 In-Reply-To: <397F31A8.1C3C32BE@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: oMJ!!J)#!!%-De9~:#e9 On Wed, 26 Jul 2000, Harold Carr wrote: > What does the CORBA 2.3 (or whatever) spec say about calls on an ORB > that is destroyed? We should considered that the ORB is essentially > destroyed when this interceptor is called so we are in the same > situation. Hmmmm. I would think, in a sense the ORB is still considered running at that point. When you are shutting down a operating system, calls to the operating system still work, or they explicitly don't. The system doesn't crash because it's undefined behavior. Oh oh, just thought of one :) .... well. Now, that I think about it, I guess that's a quality of implemenation issue I suppose. You can produce what the guys in Redmond do, or do a better job. There's nothing in the standard preventing the ORB from raising an exception and catching the exception itself, and go onto the next destroy call, eh? Cheers, -Polar > I do not think you can say "just call the next - that constrains ORB > implementations too much... > > H > > Polar Humenn wrote: > > > > On Wed, 26 Jul 2000, Harold Carr wrote: > > > > > I agree it should be prohibited - but I do not agree about an > > > exception. Who would catch the exception? The spec should just > say > > > calls are not allowed. It should probably say that results are > > > undefined if calls are attempted. > > > > Great way to crash a system. Microsoft approach. > > > > How about the interceptor call is considered over and the next > destroy > > call is processed? > > > > -Polar > > > > > > > > Matthew, if you agree along these lines, could you update your > proposal? > > > > > > H > > > > > > > > > Polar Humenn wrote: > > > > > > > > What happens if the interceptor needs to do CORBA calls while > shutting > > > > down, i.e. during "destroy()"? > > > > > > > > I imagine that this kind of thing should be prohibited? > > > > If so, it should be explicitly stated with an exception? > > > > > > > > Just asking. :) > > > > -Polar > > > > > > > > On Wed, 26 Jul 2000, Matthew Newhook wrote: > > > > > > > > > Hi, > > > > > > > > > > Proposal: > > > > > > > > > > See the issue for discussion. This proposal is to add a > destroy() method > > > > > on PortableInterceptor::Interceptor. The destroy() method > is called > > > > > upon ORB::destroy() once all outstanding requests are > complete. > > > > > > > > > > Specifics: > > > > > > > > > > Add to 21.2: > > > > > > > > > > module PortableInterceptor { > > > > > > > > > > local interface Interceptor { > > > > > readonly attribute string name; > > > > > > > > > > void destroy(); > > > > > }; > > > > > > > > > > }; > > > > > > > > > > Add a description of the destroy() operation. > > > > > > > > > > This method is called upon ORB destruction to allow the > release of > > > > > all resources associated with the interceptor. > > > > > > > > > > In section to 4.2.3.5: > > > > > > > > > > After paragraph: > > > > > > > > > > If destroy is called on an ORB that has not been shut > down, it will start > > > > > the shut down process and block until the ORB has shut > down before it > > > > > destroys the ORB. If an application calls destroy in a > thread that is > > > > > currently servicing an invocation, the BAD_INV_ORDER > system exception > > > > > will be raised with the OMG minor code 3, since blocking > would result > > > > > in a deadlock. > > > > > > > > > > Add: > > > > > > > > > > Once the shutdown process is complete, ORB::destroy() > calls the > > > > > Interceptor::destroy() operation on each registered > portable > > > > > interceptor. > > > > > > > > > > Regards, Matthew > > > > > > > > > > On Wed, Jul 26, 2000 at 09:31:47AM -0700, Harold Carr wrote: > > > > > > Could one of you two please resubmit what you want > included in the vote? > > > > > > > > > > > > Thanks, > > > > > > Harold > > > > > > > > > > > > > > > > > > Michi Henning wrote: > > > > > > > > > > > > > > On Wed, 26 Jul 2000, Matthew Newhook wrote: > > > > > > > > > > > > > > > In section to 4.2.3.5: > > > > > > > > > > > > > > That's section 4.11.5 now in the 2.3.1 spec. > > > > > > > > > > > > > > > Add: > > > > > > > > > > > > > > > > Once the shutdown process is complete the destroy() > method will be > > > > > > > > called on all registered portable interceptors. > > > > > > > > > > > > > > I would rephrase to avoid passive speech and get an > actor: > > > > > > > > > > > > > > Once the shutdown process is complete, > ORB::destroy() calls > > > > > > > the Interceptor::destroy() operation on each > registered portable > > > > > > > interceptor. > > > > > > > > > > > > > > > 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 > > > > > > > > > > -- > > > > > Matthew Newhook E-Mail: > mailto:matthew@ooc.com > > > > > Software Designer WWW: > http://www.ooc.com > > > > > Object Oriented Concepts, Inc. Phone: (709) > 738-3725 > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > Polar Humenn Adiron, LLC > > > > mailto:polar@adiron.com 2-212 CST > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 27 Jul 2000 11:06:17 +1000 (EST) From: Michi Henning To: Harold Carr cc: Matthew Newhook , interceptors-ftf@omg.org Subject: Re: issue 3435 In-Reply-To: <397F15E8.FC8409E5@sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: K]3e9G:K!!"E,e9i!R!! On Wed, 26 Jul 2000, Harold Carr wrote: > Thanks for the recap. In your proposal you put destroy on the base > Interceptor class. I would prefer that specific destroy > interceptors be > registered. Why is that? Wouldn't that make the interactions more complex? With what you suggest, I would have a number of interceptors that allocate resources and I would have a number of destroy interceptors that reclaim resources. With that kind of split, I get the problem of how to get state from the normal interceptor into the destroy interceptor. On the other hand, if destroy() is an operation on each interceptor, I don't have that problem and things are simpler. 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, 27 Jul 2000 11:07:40 +1000 (EST) From: Michi Henning To: Harold Carr cc: Matthew Newhook , interceptors-ftf@omg.org Subject: Re: issue 3435 In-Reply-To: <397F2213.2706F87D@sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: EnL!!ac>!!*Bcd9Ll+e9 On Wed, 26 Jul 2000, Harold Carr wrote: > That isn't what I said. I said the implementation derives from both > request and destroy interceptors and then registers itself twice - > once > as a destroy interceptor, and then again as a request interceptor. > No > is_a involved. What would that gain though? I can't see the benefit of this design, off-hand. 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, 27 Jul 2000 11:11:09 +1000 (EST) From: Michi Henning To: Matthew Newhook cc: Harold Carr , Polar Humenn , interceptors-ftf@omg.org Subject: Re: issue 3435 In-Reply-To: <20000726155828.A9277@ooc.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ;Om!!UC/!!?a?!!k?#"! On Wed, 26 Jul 2000, Matthew Newhook wrote: > Add a description of the destroy() operation. > > This method is called upon ORB destruction to allow the release > of > all resources associated with the interceptor. Method > invocations > on object-references belonging to the ORB being destroyed are > not > permitted and shall result in undefined behaviour. ^^^^^ Delete the "shall", otherwise we end up with an untestable requirement. How would you write a test that establishes whether the behavior is indeed undefined? :-) 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, 27 Jul 2000 11:14:32 +1000 (EST) From: Michi Henning To: Harold Carr cc: Polar Humenn , Matthew Newhook , interceptors-ftf@omg.org Subject: Re: issue 3435 In-Reply-To: <397F31A8.1C3C32BE@sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: HgHe9?5Zd9)c+!!6N7e9 On Wed, 26 Jul 2000, Harold Carr wrote: > What does the CORBA 2.3 (or whatever) spec say about calls on an ORB > that is destroyed? We should considered that the ORB is essentially > destroyed when this interceptor is called so we are in the same > situation. > > I do not think you can say "just call the next - that constrains ORB > implementations too much... My intent was that, during ORB::destroy(), the Interceptor::destroy() methods should be called while the ORB is still alive and well. That is, internally, when the client calls ORB::destroy(), the ORB: - first waits for all requests in progress to complete - then calls all the Interceptor::destroy() operations - then destroys the ORB I think we could write this into the spec, in the interest of clarity. 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, 27 Jul 2000 11:17:12 +1000 (EST) From: Michi Henning To: Harold Carr cc: Matthew Newhook , interceptors-ftf@omg.org Subject: Re: issue 3435 In-Reply-To: <397F1E19.83DB2AAC@sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: :0Je9P/e9:]H!! On Wed, 26 Jul 2000, Harold Carr wrote: > I prefer the "mixin" approach. If a ClientRequestInterceptor wants to > get a destroy notification, then the implementation of that interceptor > can derived from both ClientRequestInterceptor and ORBDestoryInterceptor > (or whatever you called it). Then it registers itself under both > categories. > > I do not like adding this to the base class at all. In other words, if > you want destroy notification, ask for it. I'm still not too keen about this approach -- what's the advantage? The presence of destroy() on the base class does not harm at all, as far as I can see. The most that is imposed on implementors is that they have to implement the destroy operation even if it is not needed. The cost of that isn't exactly large... :-) 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, 27 Jul 2000 11:26:19 +1000 (EST) From: Michi Henning To: Matthew Mihic cc: Polar Humenn , Harold Carr , Matthew Newhook , interceptors-ftf@omg.org Subject: Re: issue 3435 In-Reply-To: <397F34AC.166A369@iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: gl>e9C^%e98bo!!;^A!! On Wed, 26 Jul 2000, Matthew Mihic wrote: > The spec already says that invoking on an object reference after the ORB > has shutdown will result in a BAD_INV_ORDER exception, so I don't think > we need any special language covering this case in the Portable > Interceptor spec. I'd prefer to simply say that an exceptions raised by > the Interceptor::destroy() operation are caught by the ORB and ignored. Hmmm... I don't think that applies here though because we are inside ORB::destroy(). The spec says that invoking any operation on an ORB that is destroyed raises OBJECT_NOT_EXIST. The question is, if an interceptor uses the ORB being destroyed inside Interceptor::destroy() to make an invocation on another object, should that invocation fail or not. In other words, is the ORB considered destroyed before or after Interceptor::destroy() is called? Some thoughts: ORB::destroy() implicitly calls ORB::shutdown(true). Because Interceptor::destroy() can be called only once this implicit shutdown is complete, it seems clear that an interceptor cannot invoke operations on objects that are collocated, because the POAs for all those objects are destroyed by the time Interceptor::destroy() is called. To me, this also indicates that Interceptor::destroy() could still call operations on objects elsewhere (on another ORB, either collocated or remote) without any problem. Of course, now we get into the old collocation transparency issue again, but I don't think this can be avoided here. If I want to make sure that some collocated objects are still around during Interceptor::destroy(), I have to put them on a different ORB. 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, 26 Jul 2000 21:17:54 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Matthew Newhook , interceptors-ftf@omg.org Subject: Re: issue 3435 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ?- > On Wed, 26 Jul 2000, Harold Carr wrote: > > > Thanks for the recap. In your proposal you put destroy on the base > > Interceptor class. I would prefer that specific destroy interceptors be > > registered. > > Why is that? Wouldn't that make the interactions more complex? > > With what you suggest, I would have a number of interceptors that allocate > resources and I would have a number of destroy interceptors that reclaim > resources. With that kind of split, I get the problem of how to get state > from the normal interceptor into the destroy interceptor. On the other hand, > if destroy() is an operation on each interceptor, I don't have that problem > and things are simpler. > > 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, 26 Jul 2000 21:19:27 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Matthew Mihic , Polar Humenn , Matthew Newhook , interceptors-ftf@omg.org Subject: Re: issue 3435 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: eY$!!MM:e9jFK!!1W-!! I was going to include this proposal in vote 6 (starting 7/27) but it sounds like it still needs a little bake time... H Michi Henning wrote: > > On Wed, 26 Jul 2000, Matthew Mihic wrote: > > > The spec already says that invoking on an object reference after the ORB > > has shutdown will result in a BAD_INV_ORDER exception, so I don't think > > we need any special language covering this case in the Portable > > Interceptor spec. I'd prefer to simply say that an exceptions raised by > > the Interceptor::destroy() operation are caught by the ORB and ignored. > > Hmmm... I don't think that applies here though because we are inside > ORB::destroy(). The spec says that invoking any operation on an ORB that > is destroyed raises OBJECT_NOT_EXIST. The question is, if an interceptor > uses the ORB being destroyed inside Interceptor::destroy() to make > an invocation on another object, should that invocation fail or not. > In other words, is the ORB considered destroyed before or after > Interceptor::destroy() is called? > > Some thoughts: > > ORB::destroy() implicitly calls ORB::shutdown(true). > > Because Interceptor::destroy() can be called only once > this implicit shutdown is complete, it seems clear that > an interceptor cannot invoke operations on objects that are > collocated, because the POAs for all those objects are > destroyed by the time Interceptor::destroy() is called. > > To me, this also indicates that Interceptor::destroy() could still > call operations on objects elsewhere (on another ORB, either collocated > or remote) without any problem. > > Of course, now we get into the old collocation transparency issue again, > but I don't think this can be avoided here. If I want to make sure > that some collocated objects are still around during Interceptor::destroy(), > I have to put them on a different ORB. > > 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, 27 Jul 2000 14:25:25 +1000 (EST) From: Michi Henning To: Harold Carr cc: Matthew Newhook , interceptors-ftf@omg.org Subject: Re: issue 3435 In-Reply-To: <397FB7F2.BBD1EF1F@sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: CZ!!!Baod9W`S!!A)$e9 On Wed, 26 Jul 2000, Harold Carr wrote: > If an interceptor implementation inherits from both, say, request > interceptor and destroy interceptor and registered twice in each > category then you still get what you want - one interceptor > implementation receiving the notification - and I get what I want - > a > separate type for this interceptor. > > Seems pretty simple. Separation of concerns and all that... I don't see why it has to be so complicated though. As far as the ORB is concerned, two completely different instances are registered for interception and destruction notification. If the the IORs for the two are identical, that's merely a coincidence. What is being destroyed here is the actual interceptor, not some other object that then has the job of destroying the interceptor. Sorry, but I honestly don't see how this would achieve separation of concerns. What Matthew suggested follows the standard destruction pattern, which puts a destroy() operation on the thing to be destroyed. That seems a lot simpler to me than having two interfaces. In particular, if you have separate interfaces, how would destroy() on one interface know for which interceptor a particular call to destroy() is meant to be for? I firmly believe that putting a destroy() on the base interface is the simple and correct thing to do. > - and I get what I want - a > separate type for this interceptor. I understand the advantage of a separate type, but I see disadvantages. And it's not clear to me how the association would be made between each particular call to destroy() on the destruction interface and the interface instance being destroyed by that call. 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, 27 Jul 2000 14:25:59 +1000 (EST) From: Michi Henning To: Harold Carr cc: Matthew Mihic , Polar Humenn , Matthew Newhook , interceptors-ftf@omg.org Subject: Re: issue 3435 In-Reply-To: <397FB84F.9A0B7830@sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: >gH!!<35e9?)#!!$6 I was going to include this proposal in vote 6 (starting 7/27) but it > sounds like it still needs a little bake time... What, don't you like your roast rare? ;-) Cheers, Michi. Date: Wed, 26 Jul 2000 21:42:28 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Matthew Newhook , interceptors-ftf@omg.org Subject: Re: issue 3435 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: DfMe90/(!!Ajd!!l7,e9 Initially I thought we were just having stylistic differences. However, your statements: > ... What is being destroyed here > is the actual interceptor, not some other object that then has the > job of destroying the interceptor. I thought the destroy method was a notification that ORB::destroy has been called. I did not assume that it meant that it destroyed the interceptor after the invocation of the interceptors destroy operation completed. Is destroy being called because the ORB is being destroyed, or because the ORB is destroying the interceptor? H Date: Thu, 27 Jul 2000 14:46:42 +1000 (EST) From: Michi Henning To: Harold Carr cc: Matthew Newhook , interceptors-ftf@omg.org Subject: Re: issue 3435 In-Reply-To: <397FBDB4.24803C06@sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: MYAe9=W-e9(QMe9m`e!! On Wed, 26 Jul 2000, Harold Carr wrote: > > ... What is being destroyed here > > is the actual interceptor, not some other object that then has the > > job of destroying the interceptor. > > I thought the destroy method was a notification that ORB::destroy > > has > been called. I did not assume that it meant that it destroyed the > interceptor after the invocation of the interceptors destroy > > operation > completed. > > Is destroy being called because the ORB is being destroyed, or > > because > the ORB is destroying the interceptor? It amounts to the same thing. The interceptor may decide to commit suicide at that point, or it may decide to just clean up state and let some other part of the code get rid of the servant. Conceptually, from the ORB's perspective, the interceptor is being destroyed. A side effect would be that, after the ORB has called all the interceptor destroy() operations, it must not make any more invocations on the interceptors because they may no longer be there. (Which makes perfect sense, IMO.) 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, 26 Jul 2000 21:53:11 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Matthew Newhook , interceptors-ftf@omg.org Subject: Re: issue 3435 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: n*C!!Th@!!6Z%!!17!!! Regardless of stylistic differences, I definitely do not think the spec should say that the ORB destroys the interceptor after it calls its destory operation (and it completes). That would prevent one from, say, implementating one interceptor instance that serves as, say, an IORInterceptor, a ClientRequestInterceptor, and a ServerRequestInterceptor. It seems we provide more flexibility to just say the the destory operation is a notification that the ORB is being destroyed and that at some unspecified time after ALL destroy operations have been called and completed on ALL registered interceptors, that the interceptors are destroyed by the ORB. I do not think we should say it happens just after the operation returns for the reasons given above. H Michi Henning wrote: > > On Wed, 26 Jul 2000, Harold Carr wrote: > > > > ... What is being destroyed here > > > is the actual interceptor, not some other object that then has the > > > job of destroying the interceptor. > > > > I thought the destroy method was a notification that ORB::destroy has > > been called. I did not assume that it meant that it destroyed the > > interceptor after the invocation of the interceptors destroy operation > > completed. > > > > Is destroy being called because the ORB is being destroyed, or because > > the ORB is destroying the interceptor? > > It amounts to the same thing. The interceptor may decide to commit suicide > at that point, or it may decide to just clean up state and let some other > part of the code get rid of the servant. > > Conceptually, from the ORB's perspective, the interceptor is being destroyed. > A side effect would be that, after the ORB has called all the interceptor > destroy() operations, it must not make any more invocations on the > interceptors because they may no longer be there. (Which makes perfect > sense, IMO.) > > 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, 27 Jul 2000 15:01:11 +1000 (EST) From: Michi Henning To: Harold Carr cc: Matthew Newhook , interceptors-ftf@omg.org Subject: Re: issue 3435 In-Reply-To: <397FC037.4F4B3302@sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: l2J!!o`#!!i)4!!!;l!! On Wed, 26 Jul 2000, Harold Carr wrote: > Regardless of stylistic differences, I definitely do not think the spec > should say that the ORB destroys the interceptor after it calls its > destory operation (and it completes). The ORB can't possibly destroy an interceptor instance because it doesn't know how. The only thing that can be destroyed is the servant, and that is completely under control of the interceptor implementor. All the ORB can do is forget (release) its reference to the interceptor. > That would prevent one from, say, > implementating one interceptor instance that serves as, say, an > IORInterceptor, a ClientRequestInterceptor, and a > ServerRequestInterceptor. That's not prevented at all. I can still have destroy() on the base interface and register the same interceptor instance multiple times. In that case, my implementation of destroy() simply counts the number of calls and destroys the servant only when the final destroy() call has arrived. > It seems we provide more flexibility to just say the the destory > operation is a notification that the ORB is being destroyed That's all it is, either way. The only understanding must be that, once the ORB has called destroy() on a particular copy of an object reference to an interceptor, it must release that reference and forget it. (Of course, other copies of the same reference to the same interceptor may still be registered as if they pointed at other, unrelated interceptors, and the ORB will call destroy() on those just the same.) > and that at > some unspecified time after ALL destroy operations have been called > and > completed on ALL registered interceptors, that the interceptors are > destroyed by the ORB. The ORB cannot possible destroy an interceptor. Interceptors must destroy themselves. The only thing the ORB can do is invoke the destroy() operation and then release the reference. > I do not think we should say it happens just > after the operation returns for the reasons given above. It doesn't happen! 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, 26 Jul 2000 22:06:06 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Matthew Newhook , interceptors-ftf@omg.org Subject: Re: issue 3435 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: +O2!!k;)!!=Q/!!'XL!! OK. I think we are on the same page. I do not think it is productive for me to try to convince you to do a separate type. I think it would now be more productive for you to continue baking the proposal with regard to some of the more serious semantic concerns raised by Paul and others. Thanks, Harold Michi Henning wrote: > > On Wed, 26 Jul 2000, Harold Carr wrote: > > > Regardless of stylistic differences, I definitely do not think the spec > > should say that the ORB destroys the interceptor after it calls its > > destory operation (and it completes). > > The ORB can't possibly destroy an interceptor instance because it doesn't > know how. The only thing that can be destroyed is the servant, and that > is completely under control of the interceptor implementor. All the ORB > can do is forget (release) its reference to the interceptor. > > > That would prevent one from, say, > > implementating one interceptor instance that serves as, say, an > > IORInterceptor, a ClientRequestInterceptor, and a > > ServerRequestInterceptor. > > That's not prevented at all. I can still have destroy() on the base interface > and register the same interceptor instance multiple times. In that case, > my implementation of destroy() simply counts the number of calls and destroys > the servant only when the final destroy() call has arrived. > > > It seems we provide more flexibility to just say the the destory > > operation is a notification that the ORB is being destroyed > > That's all it is, either way. The only understanding must be that, once > the ORB has called destroy() on a particular copy of an object reference > to an interceptor, it must release that reference and forget it. (Of course, > other copies of the same reference to the same interceptor may still be > registered as if they pointed at other, unrelated interceptors, and > the ORB will call destroy() on those just the same.) > > > and that at > > some unspecified time after ALL destroy operations have been called and > > completed on ALL registered interceptors, that the interceptors are > > destroyed by the ORB. > > The ORB cannot possible destroy an interceptor. Interceptors must destroy > themselves. The only thing the ORB can do is invoke the destroy() operation > and then release the reference. > > > I do not think we should say it happens just > > after the operation returns for the reasons given above. > > It doesn't happen! > > 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, 01 Aug 2000 14:17:58 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: michi@ooc.com.au, matthew@ooc.com CC: interceptors-ftf@omg.org Subject: 3435 - Interceptors and finalization Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: YW~e9*m$e92,Ie9S\@!! Matthew and Michi, Last week I received a proposal and then an updated proposal from Matthew. Then some mail from Michi suggesting a slight change. Then some mail from other FTF members asking for more clarification. Etc. Anyway, if you would like this to be included in vote 7 (the last vote) please send the current version. Thanks, Harold Date: Wed, 2 Aug 2000 07:23:24 +1000 (EST) From: Michi Henning To: Harold Carr cc: matthew@ooc.com, interceptors-ftf@omg.org Subject: Re: 3435 - Interceptors and finalization In-Reply-To: <39873E86.4BDDB023@sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: GX9e9Q&R!!6@Qe92YF!! On Tue, 1 Aug 2000, Harold Carr wrote: > Matthew and Michi, > > Last week I received a proposal and then an updated proposal from > Matthew. Then some mail from Michi suggesting a slight change. > Then > some mail from other FTF members asking for more clarification. > Etc. > > Anyway, if you would like this to be included in vote 7 (the last > vote) > please send the current version. Matthew is on leave at the moment. Harold, if you can forward me the last version (or point me at the right place in the archive), I'll send an update. (Sorry, but I almost certainly deleted the original e-mails.) 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, 01 Aug 2000 14:33:52 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: matthew@ooc.com, interceptors-ftf@omg.org Subject: Re: 3435 - Interceptors and finalization References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: -]6e9A!C!!*bkd9YK&!! Michi, I do not have it. You will need to dig it out of: http://cgi.omg.org/issues/issue3435.txt Cheers, H Michi Henning wrote: > > On Tue, 1 Aug 2000, Harold Carr wrote: > > > Matthew and Michi, > > > > Last week I received a proposal and then an updated proposal from > > Matthew. Then some mail from Michi suggesting a slight change. Then > > some mail from other FTF members asking for more clarification. Etc. > > > > Anyway, if you would like this to be included in vote 7 (the last vote) > > please send the current version. > > Matthew is on leave at the moment. Harold, if you can forward me the > last version (or point me at the right place in the archive), I'll send > an update. (Sorry, but I almost certainly deleted the original e-mails.) > > 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 Sender: Harold.Carr@eng.sun.com Message-ID: <398A12CB.2D9E5BC9@Sun.COM> Date: Thu, 03 Aug 2000 17:48:11 -0700 From: Harold Carr Organization: Sun Microsystems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ioana Pirvulescu CC: Michi Henning , juergen@omg.org, interceptors-ftf@omg.org Subject: Re: Issue 3435 References: <398A0D75.DE9AD09F@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: XH:e9Dn@e9Dm!!!b\V!! Ioana Pirvulescu wrote: > > So the question is do we want to extend our request-level > interceptors to > include orb lifecycle points, or do we want a true orb lifecycle > interface that > interceptors (or others) can implement? I'm a bit uncomfortable with > the > former... > Yes, this seems to reinforce what I was asking of this proposal last week: define an ORBDestroyInterceptor rather than putting a destroy method on all interceptors. I still prefer that style. Cheers, Harold From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: VOTE 7 issues Date: Tue, 15 Aug 2000 10:32:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: od)e9Q[e!!h)(e9,d_!! > From: Bob Kukura [mailto:kukura@iona.com] > 3435 - No - I support the general idea, but what is needed is > a shutdown > operation, not a destroy operation. The interceptors need to > be informed > when the ORB is shutting down, not when it is being > destroyed. Also, its > not clear that the interceptors should be informed while the > client side > of the ORB is still functional (which is definitely before shutdown > completes and probably before destroy is called), or when the > client and > server sides have both been shutdown, or possibly before even > the server > side shutdown has begun, or maybe some combination of these. If a > destroy operation is voted in, we will definitely need a > followup issue > to fix the text to be consistent with server side and client side > shutdown having occured before destroy. I'm also not sure when > references to the interceptors are released by the ORB, and how that > relates to shutdown and destroy. Bob makes good points. Once again we dig deeper into the ORB state machine - needing specific states when client references work, when servers work, etc. Obviously all orbs have some notion of this, but the devil is in the details, and it may be difficult to come up with a state model that all can live with. But this is what we need to make progress on many fronts. Paul Date: Wed, 16 Aug 2000 07:30:12 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interceptors-ftf@omg.org Subject: RE: VOTE 7 issues In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BF91@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: )eed9B9nd93o:!!i~f!! On Tue, 15 Aug 2000, Paul Kyzivat wrote: > > From: Bob Kukura [mailto:kukura@iona.com] > > > 3435 - No - I support the general idea, but what is needed is > > a shutdown > > operation, not a destroy operation. The interceptors need to > > be informed > > when the ORB is shutting down, not when it is being > > destroyed. Why is this? I thought that ORB::destroy() was the right time to inform the interceptors. That's because shutdown() only terminates the run loop and doesn't destroy the ORB. For example, I could call ORB::shutdown() followed by ORB_init() with the same ORB identifier, and I would still get the same ORB with all its interceptors still attached. > > Also, its > > not clear that the interceptors should be informed while the > > client side > > of the ORB is still functional (which is definitely before > > shutdown > > completes and probably before destroy is called), or when the > > client and > > server sides have both been shutdown, or possibly before even > > the server > > side shutdown has begun, or maybe some combination of these. If a > > destroy operation is voted in, we will definitely need a > > followup issue > > to fix the text to be consistent with server side and client side > > shutdown having occured before destroy. I'm also not sure when > > references to the interceptors are released by the ORB, and how > > that > > relates to shutdown and destroy. The way I saw it, when the application calls ORB::destroy(), the ORB calls Interceptor::destroy() on each interceptor and then releases the reference to each interceptor. I think that would work. > Bob makes good points. > > Once again we dig deeper into the ORB state machine - needing > specific > states when client references work, when servers work, > etc. Obviously > all orbs have some notion of this, but the devil is in the details, > and it may be difficult to come up with a state model that all can > live > with. > But this is what we need to make progress on many fronts. I'm afraid that you are right. 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