Issue 3976: Harmful deprecation of LOCATE_FORWARD_PERM for Faut Tolerant CORBA (ft-ftf) Source: Alcatel-Lucent (Dr. Julien Maisonneuve, Ph.D., julien.maisonneuve(at)alcatel-lucent.com) Nature: Uncategorized Issue Severity: Summary: Earlier this year, the interop FTF deprecated the LOCATE_FORWARD_PERM exception because of several reasons : - it was badly specified - it made the implementation of hash() difficult, and broke most of the existing ones. It turns out that the Fault Tolerance specification published a little earlier crucially requires a similar mechanism. In normal life, most applications can rely on plain LOCATE_FORWARD because there is no reason to expect the death of the originally pointed component. In the case of Fault Tolerant CORBA, this is entirely different: it is precisely when we issue a LOCATE_FORWARD_PERM that we know for sure that the original component is dead, and might never return. If all the backup profiles of an IOR enjoy the same death, all hope is gone. This means that without a mechanism similar to LOCATE_FORWARD_PERM, the Fault Tolerant CORBA spec cannot address the requirements of real fault-tolerant systems. This is why the Fault-Tolerant CORBA FTF would like to see LOCATE_FORWARD_PERM re-introduced in some way. Here are a few ideas that might help : Issue of scope: The scope of LOCATE_FORWARD_PERM is ORB lifetime. Issue of hash() : Let us be reminded that the Fault-Tolerant CORBA spec defines teh concept of an Interoperable Object Group Reference (IOGR). The IOGR contains a specific profile that contains a group identifier. - When an ORB receives and IOGR, it should compute the value of hash() based on the GroupID contained in the IOGR, and performs LOCATE_FORWARD_PERMs if requested. - When an ORB receives a normal IOR (i.e. an IOR lacking a group profile) it computes hash() in the customary way, and doesn't have to respond to LOCATE_FORWARD_PERMs. Resolution: see below Revised Text: The use of the LOCATE_FORWARD_PERM exception is not deprecated when it is used to return an IOGR. The use of the LOCATE_FORWARD_PERM exception to return a reference that is not an IOGR continues to be deprecated. Issue of scope: The temporal scope of the replacement reference provided by LOCATE_FORWARD_PERM is ORB lifetime or the next LOCATE_FORWARD_PERM. It is safe, and appropriate, for an ORB to replace any reference that contains the same fault tolerance domain identifier, the same object group identifier and a smaller value of the object group version. Issue of hash(): The IOGR contains an object group identifier that is unique and immutable over the lifetime of the object group. For IOGRs, the value of hash() shall be derived from the object group identifier. For references that are not IOGRs, the value of hash() will continue to be derived as at present. Revised Text: In Section 27.2.5, immediately before 27.2.5.1, insert the following paragraph: "The first of these three options, access directly to a member of a server object group, requires the use of the LOCATION_FORWARD_PERM exception. As object replicas fail and are replaced by new replicas, a stage may be reached at which all of the original replicas, cited in the original interoperable object group reference for the object, are inaccessible. Continued use of the original reference will cause system failure. The LOCATION_FORWARD_PERM exception allows such a reference to be replaced by an updated reference that contains profiles for the new replacement replicas. Thus, the LOCATION_FORWARD_PERM exception is not deprecated when it is used to return an interoperable object group reference. The use of the LOCATION_FORWARD_PERM exception to return a reference that is not an interoperable object group reference continues to be deprecated." In Section 27.2.6, after the first paragraph on page 27-21, insert the following paragraph: "The temporal scope of the replacement reference provided by LOCATION_FORWARD_PERM is ORB lifetime or the next LOCATION_FORWARD_PERM. It is safe, and appropriate, for an ORB to replace any reference that contains the same fault tolerance domain identifier, the same object group identifier and a smaller value of the version of the object group reference." In Section 27.2.3.6 on page 27-18, replace "Follows the semantics above." By: "Follows the semantics for is_equivalent(). An interoperable object group reference contains an object group identifier that is unique and immutable over the lifetime of the object group. For such a reference, the value of hash() shall be derived from the object group identifier. For references that are not interoperable object group references, the value of hash() continues to be derived as at present." Actions taken: October 19, 2000: received issue October 24, 2000: moved from interop to the Fault Tolerance FTF May 24, 2001: closed issue Discussion: End of Annotations:===== Date: Thu, 19 Oct 2000 17:38:14 +0200 (MET DST) Message-Id: <200010191538.RAA05668@hess.dinsunnet> From: Julien Maisonneuve To: interop@omg.org, core@omg.org, issues@omg.org Subject: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut Tolerant CORBA Content-Type: text X-UIDL: Qckd92J-e9?'Ke9+DS!! Earlier this year, the interop FTF deprecated the LOCATE_FORWARD_PERM exception because of several reasons : - it was badly specified - it made the implementation of hash() difficult, and broke most of the existing ones. It turns out that the Fault Tolerance specification published a little earlier crucially requires a similar mechanism. In normal life, most applications can rely on plain LOCATE_FORWARD because there is no reason to expect the death of the originally pointed component. In the case of Fault Tolerant CORBA, this is entirely different: it is precisely when we issue a LOCATE_FORWARD_PERM that we know for sure that the original component is dead, and might never return. If all the backup profiles of an IOR enjoy the same death, all hope is gone. This means that without a mechanism similar to LOCATE_FORWARD_PERM, the Fault Tolerant CORBA spec cannot address the requirements of real fault-tolerant systems. This is why the Fault-Tolerant CORBA FTF would like to see LOCATE_FORWARD_PERM re-introduced in some way. Here are a few ideas that might help : Issue of scope: The scope of LOCATE_FORWARD_PERM is ORB lifetime. Issue of hash() : Let us be reminded that the Fault-Tolerant CORBA spec defines teh concept of an Interoperable Object Group Reference (IOGR). The IOGR contains a specific profile that contains a group identifier. - When an ORB receives and IOGR, it should compute the value of hash() based on the GroupID contained in the IOGR, and performs LOCATE_FORWARD_PERMs if requested. - When an ORB receives a normal IOR (i.e. an IOR lacking a group profile) it computes hash() in the customary way, and doesn't have to respond to LOCATE_FORWARD_PERMs. best regards, Julien Maisonneuve -- Julien Maisonneuve, PhD IP Unit B1-346 Alcatel Corporate Research Center Alcanet: 2111 1577 Route de Nozay Tel: +33 1 6963 1577 91461 Marcoussis cedex Fax: +33 1 6963 1169 FRANCE Julien.Maisonneuve@alcatel.fr Date: Thu, 19 Oct 2000 12:27:16 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Julien Maisonneuve Cc: interop@omg.org, core@omg.org, issues@omg.org Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut Tolerant CORBA References: <200010191538.RAA05668@hess.dinsunnet> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Hhd!!Li"!!lRf!!6gIe9 Julien Maisonneuve wrote: > > Earlier this year, the interop FTF deprecated the LOCATE_FORWARD_PERM > exception because of several reasons : > - it was badly specified > - it made the implementation of hash() difficult, and broke most of the > existing ones. > > It turns out that the Fault Tolerance specification published a little > earlier crucially requires a similar mechanism. > In normal life, most applications can rely on plain LOCATE_FORWARD because > there is no reason to expect the death of the originally pointed component. > In the case of Fault Tolerant CORBA, this is entirely different: it is > precisely when we issue a LOCATE_FORWARD_PERM that we know for sure that > the original component is dead, and might never return. If all the backup > profiles of an IOR enjoy the same death, all hope is gone. > > This means that without a mechanism similar to LOCATE_FORWARD_PERM, the > Fault Tolerant CORBA spec cannot address the requirements of real > fault-tolerant systems. > > This is why the Fault-Tolerant CORBA FTF would like to see LOCATE_FORWARD_PERM > re-introduced in some way. Here are a few ideas that might help : > > Issue of scope: > The scope of LOCATE_FORWARD_PERM is ORB lifetime. > > Issue of hash() : > Let us be reminded that the Fault-Tolerant CORBA spec defines teh concept of > an Interoperable Object Group Reference (IOGR). The IOGR contains a specific > profile that contains a group identifier. > - When an ORB receives and IOGR, it should compute the value of hash() based > on the GroupID contained in the IOGR, and performs LOCATE_FORWARD_PERMs if > requested. > - When an ORB receives a normal IOR (i.e. an IOR lacking a group profile) it > computes hash() in the customary way, and doesn't have to respond to > LOCATE_FORWARD_PERMs. Please note that LOCATE_FORWARD_PERM is actually LOCATION_FORWARD_PERM. If perchance any document is using LCOATE_FORWARD_PERM to refer to this particular feature please do a global substitution with LOCATION_FORWARD_PERM. The description above appears to me to be a pretty accurate presentation of the discussion that Michi and I had with Julien and others in Burlingame. Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com From: Jeffrey Mischkinsky Message-Id: <200010191827.LAA28009@wheel.dcn.davis.ca.us> Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut Tolerant CORBA To: Julien.Maisonneuve@alcatel.fr (Julien Maisonneuve) Date: Thu, 19 Oct 2000 11:26:48 -0700 (PDT) Cc: interop@omg.org, core@omg.org In-Reply-To: <200010191538.RAA05668@hess.dinsunnet> from "Julien Maisonneuve" at Oct 19, 2000 05:38:14 PM X-Mailer: ELM [version 2.5 PL2] Sender: jmischki@wheel.dcn.davis.ca.us Content-Type: text X-UIDL: #k!"!\?_!!YCSd9Y*T!! 'Julien Maisonneuve' writes: > > > Earlier this year, the interop FTF deprecated the LOCATE_FORWARD_PERM > exception because of several reasons : > - it was badly specified > - it made the implementation of hash() difficult, and broke most of the > existing ones. > > It turns out that the Fault Tolerance specification published a little > earlier crucially requires a similar mechanism. > In normal life, most applications can rely on plain LOCATE_FORWARD because > there is no reason to expect the death of the originally pointed component. > In the case of Fault Tolerant CORBA, this is entirely different: it is > precisely when we issue a LOCATE_FORWARD_PERM that we know for sure that > the original component is dead, and might never return. If all the backup > profiles of an IOR enjoy the same death, all hope is gone. > > This means that without a mechanism similar to LOCATE_FORWARD_PERM, the > Fault Tolerant CORBA spec cannot address the requirements of real > fault-tolerant systems. > > This is why the Fault-Tolerant CORBA FTF would like to see LOCATE_FORWARD_PERM > re-introduced in some way. Here are a few ideas that might help : > > Issue of scope: > The scope of LOCATE_FORWARD_PERM is ORB lifetime. Although this might be an approach that has some promise, I'm not sure that this suggestion goes far enough. I don't think we have a well-defined notion of ORB "lifetime". It's certainly not tied to a process--there is no "orb process" per se. Activation/location deamons get shutdown/restarted all the time so I don't think you could use them as a proxy for an "orb", (stringified) IORs (theoretically) have an unlimited lifetime. suggestions anyone? jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Thu, 19 Oct 2000 15:13:09 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey Mischkinsky Cc: Julien Maisonneuve , interop@omg.org, orb_revision@omg.org Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut Tolerant CORBA References: <200010191826.LAA27941@wheel.dcn.davis.ca.us> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: mAld9e~Yd9;(Y!!Pj'!! Jeffrey Mischkinsky wrote: > > 'Julien Maisonneuve' writes: > > > > > > Earlier this year, the interop FTF deprecated the LOCATE_FORWARD_PERM > > exception because of several reasons : > > - it was badly specified > > - it made the implementation of hash() difficult, and broke most of the > > existing ones. > > > > It turns out that the Fault Tolerance specification published a little > > earlier crucially requires a similar mechanism. > > In normal life, most applications can rely on plain LOCATE_FORWARD because > > there is no reason to expect the death of the originally pointed component. > > In the case of Fault Tolerant CORBA, this is entirely different: it is > > precisely when we issue a LOCATE_FORWARD_PERM that we know for sure that > > the original component is dead, and might never return. If all the backup > > profiles of an IOR enjoy the same death, all hope is gone. > > > > This means that without a mechanism similar to LOCATE_FORWARD_PERM, the > > Fault Tolerant CORBA spec cannot address the requirements of real > > fault-tolerant systems. > > > > This is why the Fault-Tolerant CORBA FTF would like to see LOCATE_FORWARD_PERM > > re-introduced in some way. Here are a few ideas that might help : > > > > Issue of scope: > > The scope of LOCATE_FORWARD_PERM is ORB lifetime. > > Although this might be an approach that has some promise, I'm not sure that > this suggestion goes far enough. I don't think we have a well-defined notion of > ORB "lifetime". It's certainly not tied to a process--there is no > "orb process" per se. Activation/location deamons get shutdown/restarted all the > time so I don't think you could use them as a proxy for an "orb", > (stringified) IORs (theoretically) have an unlimited lifetime. > > suggestions anyone? I think the bottom line is that there is no way to reflect this permanent replacement in a guaranteed way in all copies of an IOR that has been externalized and stashed away somewhere. The only hope is to do this where the IOR is sitting in an active entity that potentially can originate invocations on that IOR. So I think the issue is what is the lifetime of the thing on the client side over which the LOCATION_FORWARD will be "permed". For that purpose the lifetime of a "Client ORB" to coin a term, seems to be the right scope. Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com Date: Fri, 20 Oct 2000 09:21:35 +1000 (EST) From: Michi Henning To: Jeffrey Mischkinsky cc: Interoperability RTF , core@omg.org Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut Tolerant CORBA In-Reply-To: <200010191827.LAA28009@wheel.dcn.davis.ca.us> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: lVcd9Ao>e9@>X!!\%A!! On Thu, 19 Oct 2000, Jeffrey Mischkinsky wrote: > > Issue of scope: > > The scope of LOCATE_FORWARD_PERM is ORB lifetime. > > Although this might be an approach that has some promise, I'm not > > sure that > this suggestion goes far enough. I don't think we have a > > well-defined notion of > ORB "lifetime". Huh? It seems that the lifetime of an ORB is very well defined. The ORB exist from the call to ORB_init() to the call to ORB::destroy(). 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: Jeffrey Mischkinsky Message-Id: <200010200008.RAA00828@wheel.dcn.davis.ca.us> Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut To: michi@ooc.com.au (Michi Henning) Date: Thu, 19 Oct 2000 17:07:29 -0700 (PDT) Cc: interop@omg.org (Interoperability RTF), core@omg.org In-Reply-To: from "Michi Henning" at Oct 20, 2000 09:21:35 AM X-Mailer: ELM [version 2.5 PL2] Sender: jmischki@wheel.dcn.davis.ca.us Content-Type: text X-UIDL: S`Oe9DH*e9l_B!!J@md9 'Michi Henning' writes: > > On Thu, 19 Oct 2000, Jeffrey Mischkinsky wrote: > > > > Issue of scope: > > > The scope of LOCATE_FORWARD_PERM is ORB lifetime. > > > > Although this might be an approach that has some promise, I'm not sure that > > this suggestion goes far enough. I don't think we have a well-defined notion of > > ORB "lifetime". > > Huh? It seems that the lifetime of an ORB is very well defined. The ORB > exist from the call to ORB_init() to the call to ORB::destroy(). Michi, I agree that this technically true for holding an in-memory reference to a runtime thingie that responds to operations on the ORB "psuedo-object". As Jishnu pointed out, what is really of concern here is the scope and lifetime of the "permanently" forwarded objref. I'm not sure that it is the same. For the sake of argument, let's assume for the moment that it is: So I get an objref. I do an invoke. I get a locate forward perm which means that I (the runtime) re-invokes on the new objref, under the covers, so to speak. I assume that if I re-invoke again on the original objref, I skip the interveneing step and instead use the "new" objref. Here's the question: Let's say i write out the "old" objref and then read it in having called ORB:destroy() in the meantime (or read it into a different process runing in the same ORB "domain", but obviously a different orb psuedo-object. Is the expected/required behavior that I then go through the locate forward perm steps again? I think it has to be, And I suspect it's not what was in the minds of the FT writers, but I don't understand the FT reqs well enough to be sure. If that behavior is ok, then some (probably refined) version of what you suggest mmight work. If it's not, then I think we should ask the FT folks to define exactly what it is they are looking for. jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Fri, 20 Oct 2000 10:31:50 +1000 (EST) From: Michi Henning To: Jeffrey Mischkinsky cc: Interoperability RTF , Core Revision Task Force Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut In-Reply-To: <200010200007.RAA00768@wheel.dcn.davis.ca.us> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 9~I!!S)Qd9ek$e9P~j!! On Thu, 19 Oct 2000, Jeffrey Mischkinsky wrote: > > Huh? It seems that the lifetime of an ORB is very well defined. The ORB > > exist from the call to ORB_init() to the call to ORB::destroy(). > Michi, > I agree that this technically true for holding an in-memory reference to a > runtime thingie that responds to operations on the ORB "psuedo-object". > As Jishnu pointed out, what is really of concern here is the scope and > lifetime of the "permanently" forwarded objref. I'm not sure that it > is the same. > > For the sake of argument, let's assume for the moment that it is: > So I get an objref. I do an invoke. I get a locate forward perm which > means that I (the runtime) re-invokes on the new objref, under the covers, > so to speak. I assume that if I re-invoke again on the original objref, > I skip the interveneing step and instead use the "new" objref. > > Here's the question: Let's say i write out the "old" objref and then read it > in having called ORB:destroy() in the meantime (or read it into a > different process runing in the same ORB "domain", but obviously a > different orb psuedo-object. Is the expected/required behavior that I > then go through the locate forward perm steps again? No, at least that's not what the real-time folks want. Basically, we removed permanent forwarding because of the immutability of hash() for the "lifetime of a reference" (whatever that is...) Having done that, the FT folks are complaining because they need permanent forwarding. The problem for them is that, if you have a group of replicas, it is possible that the membership of the group changes over time in such a way that none of the addresses that were written into an IOR at the time the IOR was created will be valid anymore. So, permanent location forwarding was meant to provide a way to permanently update the addressing information in an IOR. (That's also why Jon initially suggested permanent forwarding; it's one part of the object migration puzzle.) I think that we might be able to put something together that would help the FT folks along the following lines: - We need to put permanent forwarding back, at least for FT. - FT references are identifiable by their components, so we can restrict permanent forwarding to FT references *only*. - When an FT reference is permanently forwarded, the ORB receiving the forward replaces the original IOR with the new one and forgets everything about the original IOR. - In order to make hash() behave sensibly, we would need to specify the hashing algorithm *for FT IORs only*. The hash value could be computed from the group ID in some way. The drift of all this is to put permanent forwarding back into the core, but only for FT IORs. I think this could work because it would meet the needs of FT without making a mess of what's there 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 From: "Rutt, T E (Tom)" To: Jeffrey Mischkinsky , "'Michi Henning'" Cc: Interoperability RTF , Core Revision Task Force Subject: RE: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut Date: Thu, 19 Oct 2000 23:35:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: AF~!!_bW!!lkU!!a~K!! I like Michi's suggestion Tom Rutt ter ---------- From: Michi Henning [SMTP:michi@ooc.com.au] Sent: Thursday, October 19, 2000 8:32 PM To: Jeffrey Mischkinsky Cc: Interoperability RTF; Core Revision Task Force Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut I think that we might be able to put something together that would help the FT folks along the following lines: - We need to put permanent forwarding back, at least for FT. - FT references are identifiable by their components, so we can restrict permanent forwarding to FT references *only*. - When an FT reference is permanently forwarded, the ORB receiving the forward replaces the original IOR with the new one and forgets everything about the original IOR. - In order to make hash() behave sensibly, we would need to specify the hashing algorithm *for FT IORs only*. The hash value could be computed from the group ID in some way. The drift of all this is to put permanent forwarding back into the core, but only for FT IORs. I think this could work because it would meet the needs of FT without making a mess of what's there 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, 19 Oct 2000 22:30:27 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut To: michi@ooc.com.au, jmischki@wheel.dcn.davis.ca.us Cc: Ken.Cavanaugh@eng.sun.com, interop@omg.org, orb_revision@omg.org MIME-Version: 1.0 Content-MD5: 5czLH+lCLh7DyiQ8uituxQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: 8(Me9^H1e9/X@!!:Uhd9 >From: Michi Henning >To: Jeffrey Mischkinsky >cc: Interoperability RTF , Core Revision Task Force >Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for >Faut >MIME-Version: 1.0 > > >No, at least that's not what the real-time folks want. > >Basically, we removed permanent forwarding because of the >immutability of >hash() for the "lifetime of a reference" (whatever that is...) > >Having done that, the FT folks are complaining because they need >permanent >forwarding. The problem for them is that, if you have a group of >replicas, >it is possible that the membership of the group changes over time in >such >a way that none of the addresses that were written into an IOR at the >time >the IOR was created will be valid anymore. > >So, permanent location forwarding was meant to provide a way to >permanently >update the addressing information in an IOR. (That's also why Jon >initially >suggested permanent forwarding; it's one part of the object migration >puzzle.) > >I think that we might be able to put something together that would >help >the FT folks along the following lines: > > - We need to put permanent forwarding back, at least for FT. > > - FT references are identifiable by their components, so we > can restrict permanent forwarding to FT references *only*. > > - When an FT reference is permanently forwarded, the ORB >receiving > the forward replaces the original IOR with the new one and > forgets everything about the original IOR. This means that the ORB replaces all references to the original IOR in the current ORB object. If the IOR is written out to a file or obtained from a name service, those references will still refer to the old IOR, since there is no way for the ORB instances to find all possible hiding places for an IOR. It seems to me that the only meaningful way to interpret the distinction is what behavior is required in a particular ORB instance on receiving either kind of LOCATE_FORWARD. When a LOCATE_FORWARD_PERM is received, the ORB instance should replace all references that it has when the response is received with the new IOR. The behavior in the LOCATE_FORWARD case is less clear: should subsequent invocations always use the LOCATE_FORWARD value? Should certain kinds of system exceptions be interpreted to mean discard the LOCATE_FORWARD value and go back to the original value in the IOR? Something along these lines is needed to support server activation. Also, suppose I want to write a server that forwards each invocation to a (potentially) different object (e.g. a load balancing agent that forwards each request to the least utilized server, or perhaps a simple round-robin agent). In this case, I would like the client to only use the LOCATION_FORWARD ior once, getting a new one on each invocation. But there is currently no standard way to get such behavior. It seems to me that all we can specify is what happens on subsequent invocations on the same object reference, so long as the ORB instance that created the object reference continues to exist. > > - In order to make hash() behave sensibly, we would need to > specify the hashing algorithm *for FT IORs only*. The hash > value could be computed from the group ID in some way. > >The drift of all this is to put permanent forwarding back into the >core, >but only for FT IORs. I think this could work because it would meet >the >needs of FT without making a mess of what's there already. > This requires then that we move the IOGR definition (and perhaps a fair bit of FT chapter 5) into the core. Is this what we want to do here? Do we want the different possible behaviors of location forwards to be tied directly to the needs of a particular specification like FT? Thanks, Ken. Date: Fri, 20 Oct 2000 17:06:49 +1000 (EST) From: Michi Henning To: Ken Cavanaugh cc: jmischki@wheel.dcn.davis.ca.us, interop@omg.org, orb_revision@omg.org Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut In-Reply-To: <200010200530.WAA24629@taller.eng.sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: kg%e9XnL!!R4He9mpSd9 On Thu, 19 Oct 2000, Ken Cavanaugh wrote: > > - When an FT reference is permanently forwarded, the ORB receiving > > the forward replaces the original IOR with the new one and > > forgets everything about the original IOR. > > This means that the ORB replaces all references to the original IOR > in the current ORB object. If the IOR is written out to a file or > obtained from a name service, those references will still refer to > the old IOR, since there is no way for the ORB instances to find all > possible hiding places for an IOR. Yes, that's right. However, this limitation is acceptable to the FT folks. In general, with the unlimited propagation of references permitted by the CORBA object model, it is impossible to know when a reference goes stale anyway. > It seems to me that the only meaningful way to interpret the distinction > is what behavior is required in a particular ORB instance on receiving > either kind of LOCATE_FORWARD. When a LOCATE_FORWARD_PERM is received, > the ORB instance should replace all references that it has when the > response is received with the new IOR. Yes. > The behavior in the > LOCATE_FORWARD case is less clear: should subsequent invocations > always > use the LOCATE_FORWARD value? Should certain kinds of system > exceptions > be interpreted to mean discard the LOCATE_FORWARD value and go back > to the > original value in the IOR? Something along these lines is needed to > support server activation. That's really not an issue I think, because the rules we have currently already apply for LOCATE_FORWARD. Normally, the ORB will continue to use the forwarded location until that connection fails for some reason; the original location is attempted again before propagating an exception to the application. (At least, this describes the current behavior of most ORBs.) > Also, suppose I want to write a server that forwards each invocation to > a (potentially) different object (e.g. a load balancing agent that forwards > each request to the least utilized server, or perhaps a simple round-robin > agent). In this case, I would like the client to only use the LOCATION_FORWARD > ior once, getting a new one on each invocation. But there is currently > no standard way to get such behavior. Yes. But, I think that particular issue is not related to LOCATION_FORWARD_PERM (only to LOCATION_FORWARD), so I think we should address this as part of a separate issue. (Many ORBs already have proprietary configuration mechanisms to permit tinkering with the client-side binding algorithms.) > It seems to me that all we can specify is what happens on subsequent invocations > on the same object reference, so long as the ORB instance that created > the object reference continues to exist. I'm not sure I understand what you mean by this. Can you elaborate? As far as I am concerned, a LOCATION_FORWARD_PERM simply overwrites or replaces all knowledge about the previous IOR/proxy. I think that's pretty much all that needs to be said. > > - In order to make hash() behave sensibly, we would need to > > specify the hashing algorithm *for FT IORs only*. The hash > > value could be computed from the group ID in some way. > > > >The drift of all this is to put permanent forwarding back into the core, > >but only for FT IORs. I think this could work because it would meet the > >needs of FT without making a mess of what's there already. > > > > This requires then that we move the IOGR definition (and perhaps a fair > bit of FT chapter 5) into the core. Is this what we want to do here? > Do we want the different possible behaviors of location forwards to be > tied directly to the needs of a particular specification like FT? The idea to restrict permanent forwarding to FT was motivated by the problems we ran into in the core. In particular, there is no sensible way to keep the requirement for hash() to return an immutable value in the presence for (general) permanent forwarding. That's why we removed LOCATION_FORWARD_PERM again. But the FT people need it. So, as a compromise, the idea was to restrict the feature to FT only. For FT, we can avoid the hash() problem by defining the algorithm that's used to compute the hash value from the group ID. That ensures that, for all ORBs, and FT IOR has the same hash value regardless of how many times it was forwarded. 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, 20 Oct 2000 07:32:42 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Ken Cavanaugh , jmischki@wheel.dcn.davis.ca.us, interop@omg.org, orb_revision@omg.org Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Q\;!!?o"e9J\?e9ZODe9 > > The behavior in the > > LOCATE_FORWARD case is less clear: should subsequent invocations > > always > > use the LOCATE_FORWARD value? Should certain kinds of system > > exceptions > > be interpreted to mean discard the LOCATE_FORWARD value and go > > back to the > > original value in the IOR? Something along these lines is needed > > to > > support server activation. > > That's really not an issue I think, because the rules we have > > currently > already apply for LOCATE_FORWARD. Normally, the ORB will continue to > > use > the forwarded location until that connection fails for some reason; > the original location is attempted again before propagating an > > exception > to the application. (At least, this describes the current behavior > > of > most ORBs.) Which rules are you referring too? Chapter/verse please. FWIW: PI states that once you have received a LOCATION_FORWARD then subsequent invocations use the forwarded ref (ptc/00-08-06 21.3.13.2). It doesn't say under what conditions it reverts to the original ref. Cheers, H Date: Fri, 20 Oct 2000 11:06:56 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning Cc: Jeffrey Mischkinsky , Interoperability RTF , Core Revision Task Force Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: C0 > On Thu, 19 Oct 2000, Jeffrey Mischkinsky wrote: > > > > Huh? It seems that the lifetime of an ORB is very well defined. The ORB > > > exist from the call to ORB_init() to the call to ORB::destroy(). > > Michi, > > I agree that this technically true for holding an in-memory reference to a > > runtime thingie that responds to operations on the ORB "psuedo-object". > > As Jishnu pointed out, what is really of concern here is the scope and > > lifetime of the "permanently" forwarded objref. I'm not sure that it > > is the same. > > > > For the sake of argument, let's assume for the moment that it is: > > So I get an objref. I do an invoke. I get a locate forward perm which > > means that I (the runtime) re-invokes on the new objref, under the covers, > > so to speak. I assume that if I re-invoke again on the original objref, > > I skip the interveneing step and instead use the "new" objref. > > > > Here's the question: Let's say i write out the "old" objref and then read it > > in having called ORB:destroy() in the meantime (or read it into a > > different process runing in the same ORB "domain", but obviously a > > different orb psuedo-object. Is the expected/required behavior that I > > then go through the locate forward perm steps again? > > No, at least that's not what the real-time folks want. > > Basically, we removed permanent forwarding because of the immutability of > hash() for the "lifetime of a reference" (whatever that is...) > > Having done that, the FT folks are complaining because they need permanent > forwarding. The problem for them is that, if you have a group of replicas, > it is possible that the membership of the group changes over time in such > a way that none of the addresses that were written into an IOR at the time > the IOR was created will be valid anymore. > > So, permanent location forwarding was meant to provide a way to permanently > update the addressing information in an IOR. (That's also why Jon initially > suggested permanent forwarding; it's one part of the object migration puzzle.) > > I think that we might be able to put something together that would help > the FT folks along the following lines: > > - We need to put permanent forwarding back, at least for FT. > > - FT references are identifiable by their components, so we > can restrict permanent forwarding to FT references *only*. > > - When an FT reference is permanently forwarded, the ORB receiving > the forward replaces the original IOR with the new one and > forgets everything about the original IOR. > > - In order to make hash() behave sensibly, we would need to > specify the hashing algorithm *for FT IORs only*. The hash > value could be computed from the group ID in some way. > > The drift of all this is to put permanent forwarding back into the core, > but only for FT IORs. I think this could work because it would meet the > needs of FT without making a mess of what's there already. I think the answer to the question that Jeff could be framed in the form of this scenario: 1. A client ORB receives a LOCATION_FORWARD_PERM on an IOGR, and does the thing about replacing the info in the original IOGR with the new info. 2. Then the client does an object_to_string on this IOGR in question and saves that away somewhere as say StringifiedIOGR. 3. The ORB that did all this is destroyed. 4. A new ORB is inited. 5. string_to_object(StringifiedIOGR) is executed on this ORB. Does this ORB get the IOGR as modified by the LOCATION_FORWARD_PERM or the non-modified one. I think the answer should be that it gets the modified version because doing it any other way takes more effort. So in this sense the LOCATION_FORWARD_PERM does outlive the lifetime of the ORB in which the change was made. But, this did not happen automatically. Specific explicit steps had to be taken to make this happen, and I think that is OK. A related question would be which version of the IOGR is passed as a parameter in an invocation from another client, or to another server? Clearly it should be the modified one, and if that ORB outlives this one, then the modified IOGR will outlive the ORB in which it was modified. Of course the way Jeff poses the question is "Is the expected/required behavior that I then go through the locate forward perm steps again?". The answer depends on who the "I" is. The general answer is, assuming that "I" is the client ORB involved, you just do an invocation as usual. If the target has not moved further along the invocation will succeed as is. If it has moved further along and the place from where it moved is still alive enough to send another LOCATION_FORWARD_PERM, you'll get a LOCATION_FORWARD_PERM and deal with it as usual. Now the other thing that we need to nail down is what happens when a server side ORB sends a LOCATION_FORWARD_PERM in response to an invocation on a non-IOGR IOR: 1. Is this going to be valid behavior? 1.a. If Yes then should the client ORB treat this purely as a LOCATION_FORWARD and be done with it? 1.b. If No what is the client ORB to do? It seems to me the easiest thing to do is allow this to be valid behavior. and go for 1.a. Comments? Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com Date: Fri, 20 Oct 2000 13:26:30 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut To: Ken.Cavanaugh@eng.sun.com, michi@ooc.com.au Cc: jmischki@wheel.dcn.davis.ca.us, interop@omg.org, orb_revision@omg.org MIME-Version: 1.0 Content-MD5: e3wf1NB7LFd3HOaUB0Ionw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: JA9!!de2!!J#%e9-6[d9 >From: Michi Henning >To: Ken Cavanaugh >cc: jmischki@wheel.dcn.davis.ca.us, interop@omg.org, >orb_revision@omg.org >Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for >Faut >MIME-Version: 1.0 > >On Thu, 19 Oct 2000, Ken Cavanaugh wrote: > >> > - When an FT reference is permanently forwarded, the ORB >receiving >> > the forward replaces the original IOR with the new one and >> > forgets everything about the original IOR. >> >> This means that the ORB replaces all references to the original IOR >> in the current ORB object. If the IOR is written out to a file or >> obtained from a name service, those references will still refer to >> the old IOR, since there is no way for the ORB instances to find >all >> possible hiding places for an IOR. > >Yes, that's right. However, this limitation is acceptable to the FT >folks. >In general, with the unlimited propagation of references permitted >by the CORBA object model, it is impossible to know when a reference >goes stale anyway. > >> It seems to me that the only meaningful way to interpret the >distinction >> is what behavior is required in a particular ORB instance on >receiving >> either kind of LOCATE_FORWARD. When a LOCATE_FORWARD_PERM is >received, >> the ORB instance should replace all references that it has when the >> response is received with the new IOR. > >Yes. > >> The behavior in the >> LOCATE_FORWARD case is less clear: should subsequent invocations >always >> use the LOCATE_FORWARD value? Should certain kinds of system >exceptions >> be interpreted to mean discard the LOCATE_FORWARD value and go back >to the >> original value in the IOR? Something along these lines is needed >to >> support server activation. > >That's really not an issue I think, because the rules we have >currently >already apply for LOCATE_FORWARD. Normally, the ORB will continue to >use >the forwarded location until that connection fails for some reason; >the original location is attempted again before propagating an >exception >to the application. (At least, this describes the current behavior of >most ORBs.) > That's what I would expect. However, it would make sense to try to nail this part of the spec down a little better too, I think. It is not part of the "CORBA FT needs LOCATION_FORWARD_PERM issue", rather it's a "precisely specify the semantics of location forwarding" issue. >> Also, suppose I want to write a server that forwards each invocation to >> a (potentially) different object (e.g. a load balancing agent that forwards >> each request to the least utilized server, or perhaps a simple round-robin >> agent). In this case, I would like the client to only use the LOCATION_FORWARD >> ior once, getting a new one on each invocation. But there is currently >> no standard way to get such behavior. > >Yes. But, I think that particular issue is not related to >LOCATION_FORWARD_PERM (only to LOCATION_FORWARD), so I think we should address >this as part of a separate issue. (Many ORBs already have proprietary >configuration mechanisms to permit tinkering with the client-side binding >algorithms.) > >> It seems to me that all we can specify is what happens on subsequent invocations >> on the same object reference, so long as the ORB instance that created >> the object reference continues to exist. > >I'm not sure I understand what you mean by this. Can you elaborate? Something like the following: If a client invocation on an object reference O1 with IOR I1 receives a LOCATION_FORWARD_PERM containing IOR I2, all subsequent invocations by the client on O1 will be sent to I2. If a client invocation on an object reference O1 with IOR I1 receives a LOCATION_FORWARD containing IOR I2, all subsequent invocations by the client on O1 will be sent to I2, unless an error (in a certain class that needs to be specified, e.g. COMM_FAILURE with COMPLETED_NO) is received, in which case the request will be retried with IOR I1. Of course, FT also makes statements about the retry behavior, including the same error that I mentioned above. Perhaps we need to specify different behavior for ordinary IORs (i.e. the standard behavior that is mostly expected but unspecified) and IOGRS (which is well specified in the FT spec). We could look at this as 4 cases: IOR LF PERM this is an error that is reported to the application? IOR LF normal behavior (use LF IOR until failure, then rebind) IOGR LF PERM special (never use old IOR again) IOGR LF normal behavior (use LF IOR until failure, then rebind) The case of an invocation on an IOGR that results in a LF containing a normal IOR seems to work OK here, in that a rebind sends us back to the original IOGR and invokes the CORBA FT rules. How do the LF types mix? It seems like an LF PERM must always contain an IOGR, while an LF could contain either an IOR or an IOGR. Is this correct? >As far as I am concerned, a LOCATION_FORWARD_PERM simply overwrites >or replaces all knowledge about the previous IOR/proxy. I think >that's >pretty much all that needs to be said. > >> > - In order to make hash() behave sensibly, we would need to >> > specify the hashing algorithm *for FT IORs only*. The hash >> > value could be computed from the group ID in some way. >> > >> >The drift of all this is to put permanent forwarding back into the >core, >> >but only for FT IORs. I think this could work because it would >meet the >> >needs of FT without making a mess of what's there already. >> > >> >> This requires then that we move the IOGR definition (and perhaps a >fair >> bit of FT chapter 5) into the core. Is this what we want to do >here? >> Do we want the different possible behaviors of location forwards to >be >> tied directly to the needs of a particular specification like FT? > >The idea to restrict permanent forwarding to FT was motivated by the >problems we ran into in the core. In particular, there is no sensible >way to keep the requirement for hash() to return an immutable value >in the presence for (general) permanent forwarding. That's why we >removed LOCATION_FORWARD_PERM again. But the FT people need it. So, >as a compromise, the idea was to restrict the feature to FT only. For >FT, we can avoid the hash() problem by defining the algorithm that's >used >to compute the hash value from the group ID. That ensures that, for >all >ORBs, and FT IOR has the same hash value regardless of how many times >it >was forwarded. > I understand this. I just want to understand how much moves into the core. Certainly all of the definition of TAG_GROUP component is needed, plus the discussion in CORBA FT section 5.2.3 on is_equivalent and hash, which essentially says what the core needs to say (in particular, is_equivalent and hash are determined by the values of the ft_domain_id and object_group_id fields). Do we need to also move TAG_PRIMARY component into the core? This would give us the complete IOGR definition in the core. Thanks, Ken. Date: Fri, 20 Oct 2000 18:01:54 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ken Cavanaugh Cc: michi@ooc.com.au, jmischki@wheel.dcn.davis.ca.us, interop@omg.org, orb_revision@omg.org Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut References: <200010202026.NAA18221@taller.eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: `'H!!EZHe9eXIe9V+o!! Ken Cavanaugh wrote: > > > > >The idea to restrict permanent forwarding to FT was motivated by > >the > >problems we ran into in the core. In particular, there is no > >sensible > >way to keep the requirement for hash() to return an immutable value > >in the presence for (general) permanent forwarding. That's why we > >removed LOCATION_FORWARD_PERM again. But the FT people need it. So, > >as a compromise, the idea was to restrict the feature to FT > >only. For > >FT, we can avoid the hash() problem by defining the algorithm > >that's used > >to compute the hash value from the group ID. That ensures that, for > >all > >ORBs, and FT IOR has the same hash value regardless of how many > >times it > >was forwarded. > > > > I understand this. I just want to understand how much moves into > >the core. > Certainly all of the definition of TAG_GROUP component is needed, > >plus > the discussion in CORBA FT section 5.2.3 on is_equivalent and hash, > >which > essentially says what the core needs to say (in particular, > >is_equivalent > and hash are determined by the values of the ft_domain_id and > >object_group_id > fields). Do we need to also move TAG_PRIMARY component into the > >core? > This would give us the complete IOGR definition in the core. I think inevitably the IOGR stuff will have to be included in the published core specs. Now whether a product must contain all of that is a separate issue. Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com Date: Mon, 23 Oct 2000 03:54:52 -0700 From: "M. Mortazavi" X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Ken Cavanaugh , jmischki@wheel.dcn.davis.ca.us, interop@omg.org, orb_revision@omg.org Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: dbS!!F,Be9?@4!!nX~!! Michi Michi Henning wrote: > The idea to restrict permanent forwarding to FT was motivated by the > problems we ran into in the core. In particular, there is no > sensible > way to keep the requirement for hash() to return an immutable value > in the presence for (general) permanent forwarding. That's why we > removed LOCATION_FORWARD_PERM again. But the FT people need it. So, > as a compromise, the idea was to restrict the feature to FT > only. For > FT, we can avoid the hash() problem by defining the algorithm that's > used > to compute the hash value from the group ID. That ensures that, for > all > ORBs, and FT IOR has the same hash value regardless of how many > times it > was forwarded. FT has a clear need for LOCATION_FORWARD_PERM or somthing like it to support, *only-forward* evolution of an FT IOGR. However, the problem with hash exists and needs to be resolved (or taken care of) for IOGR's. One way to do this is as Michi suggested, based on the group ID. Max Date: Mon, 23 Oct 2000 04:20:09 -0700 From: "M. Mortazavi" X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rutt, T E (Tom)" CC: Jeffrey Mischkinsky , "'Michi Henning'" , Interoperability RTF , Core Revision Task Force Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 2I?e9)7@!!<_Pd9cXCe9 "Rutt, T E (Tom)" wrote: > I like Michi's suggestion > > Tom Rutt > > ter > > ---------- > From: Michi Henning [SMTP:michi@ooc.com.au] > Sent: Thursday, October 19, 2000 8:32 PM > To: Jeffrey Mischkinsky > Cc: Interoperability RTF; Core Revision Task Force > Subject: Re: Issue of harmful deprecation of >LOCATE_FORWARD_PERM > for Faut > > I think that we might be able to put something together that >would > help > the FT folks along the following lines: > > - We need to put permanent forwarding back, at least >for FT. a "forward-only" update of IOR(IOGR) is necessary for FT > > > - FT references are identifiable by their >components, so we > can restrict permanent forwarding to FT references >*only*. > > - When an FT reference is permanently forwarded, the >ORB > receiving > the forward replaces the original IOR with the new >one and > forgets everything about the original IOR. i.e. "forward-only" > - In order to make hash() behave sensibly, we would need to > specify the hashing algorithm *for FT IORs only*. The hash > value could be computed from the group ID in some way. some FT people suggested this, as well. > > > The drift of all this is to put permanent forwarding back >into the > core, > but only for FT IORs. I think this could work because it >would meet > the > needs of FT without making a mess of what's there already. while this'll work, since this is only for FT, wouldn't it be better to see--now that it or something like it will go back in--whether they would have liked to see something a bit more suitable, or more general. For example, an IOR Update reply message with a field that gives some data structure for the mode of the IOR update, could be very useful, much more useful than a location forward permanent. If there's an IOR update message, let's make it somewhat more general. Some modes of update (such as "permanent or forward-only") could be part of the specifications. I think this might be an approach worth exploring. Cheers, Max > > 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: Mon, 23 Oct 2000 11:43:00 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "M. Mortazavi" Cc: "Rutt, T E (Tom)" , Jeffrey Mischkinsky , "'Michi Henning'" , Interoperability RTF , Core Revision Task Force Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut References: <39F41EE9.7C6DF5F0@eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ]k7e91VB!!fBgd9[~0!! "M. Mortazavi" wrote: > > "Rutt, T E (Tom)" wrote: > > > I like Michi's suggestion > > > > Tom Rutt > > > > ter > > > > ---------- > > From: Michi Henning [SMTP:michi@ooc.com.au] > > Sent: Thursday, October 19, 2000 8:32 PM > > To: Jeffrey Mischkinsky > > Cc: Interoperability RTF; Core Revision Task Force > > Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM > > for Faut > > > > I think that we might be able to put something together that would > > help > > the FT folks along the following lines: > > > > - We need to put permanent forwarding back, at least for FT. > > a "forward-only" update of IOR(IOGR) is necessary for FT > > > > > > > - FT references are identifiable by their components, so we > > can restrict permanent forwarding to FT references *only*. > > > > - When an FT reference is permanently forwarded, the ORB > > receiving > > the forward replaces the original IOR with the new one and > > forgets everything about the original IOR. > > i.e. "forward-only" > > > - In order to make hash() behave sensibly, we would need to > > specify the hashing algorithm *for FT IORs only*. The hash > > value could be computed from the group ID in some way. > > some FT people suggested this, as well. > > > > > > > The drift of all this is to put permanent forwarding back into the > > core, > > but only for FT IORs. I think this could work because it would meet > > the > > needs of FT without making a mess of what's there already. > > while this'll work, since this is only for FT, wouldn't it be better to see--now > that it or something like it will go back in--whether they would have liked to > see something a bit more suitable, or more general. For example, an IOR Update > reply message with a field that gives some data structure for the mode of the > IOR update, could be very useful, much more useful than a location forward > permanent. If there's an IOR update message, let's make it somewhat more > general. Some modes of update (such as "permanent or forward-only") could be > part of the specifications. I think this might be an approach worth exploring. The conservative in me says that this sort of on the fly feturelet additions through RTFs should be discouraged, so I will tend to vote against this sort of thing. It is not just a matter of adding another message, but also figuring out what the recipient of the message is to do with it, not just in the FT space, but affecting all general purpose ORBs in potentially backward incompatible ways. We are yet to completely figure out what to do with a simple LOCATION_FORWARD_PERM. Lets get that done addressing the immediate issue that the FT spec has, and leave other fancy enhancements for future RFPs. Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com Date: Tue, 24 Oct 2000 08:49:31 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Ken Cavanaugh , jmischki@wheel.dcn.davis.ca.us, interop@omg.org, orb_revision@omg.org Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: :4e!!^9kd9!Cfd9B%jd9 I've been traveling and away from email the since last Thursday, and haven't completely caught up on this thread. But I thought I'd state my position on this issue. I don't think its the lifespan of LOCATION_FORWARD_PERM thats the problem - its the lifespan of the hash function. All the ORBs I've worked on treat the lifespan of the hash result as bounded by the lifetime of the reference within the process. If another process calls hash on a reference, its likely to get a different hash value. This is adequate for in-memory hash tables, and as far as I am aware, is all that is currently required by the specification. No customers have complained. But I admit this isn't the only way to interpret the spec. So my position is that all we need to do is clarify that this how hash may behave, and then we don't need to worry about location forward permanent changing the hash result when the forwarded IOR is sent to a different process. The original process can keep both around, and ensure that the hash value from the original IOR is returned. I am opposed to any attempt to make the core aware of a distinction between "FT" and "normal" IORs. Also, I thought the main issue with LFP was not the hash problem, but the fact that CORBA provided no mechanism to inform the application that a reference stored persistently needed to be updated. Is this still a concern? -Bob Michi Henning wrote: > > On Thu, 19 Oct 2000, Ken Cavanaugh wrote: > > > > - When an FT reference is permanently forwarded, the ORB receiving > > > the forward replaces the original IOR with the new one and > > > forgets everything about the original IOR. > > > > This means that the ORB replaces all references to the original IOR > > in the current ORB object. If the IOR is written out to a file or > > obtained from a name service, those references will still refer to > > the old IOR, since there is no way for the ORB instances to find all > > possible hiding places for an IOR. > > Yes, that's right. However, this limitation is acceptable to the FT folks. > In general, with the unlimited propagation of references permitted > by the CORBA object model, it is impossible to know when a reference > goes stale anyway. > > > It seems to me that the only meaningful way to interpret the distinction > > is what behavior is required in a particular ORB instance on receiving > > either kind of LOCATE_FORWARD. When a LOCATE_FORWARD_PERM is received, > > the ORB instance should replace all references that it has when the > > response is received with the new IOR. > > Yes. > > > The behavior in the > > LOCATE_FORWARD case is less clear: should subsequent invocations always > > use the LOCATE_FORWARD value? Should certain kinds of system exceptions > > be interpreted to mean discard the LOCATE_FORWARD value and go back to the > > original value in the IOR? Something along these lines is needed to > > support server activation. > > That's really not an issue I think, because the rules we have currently > already apply for LOCATE_FORWARD. Normally, the ORB will continue to use > the forwarded location until that connection fails for some reason; > the original location is attempted again before propagating an exception > to the application. (At least, this describes the current behavior of > most ORBs.) > > > Also, suppose I want to write a server that forwards each invocation to > > a (potentially) different object (e.g. a load balancing agent that forwards > > each request to the least utilized server, or perhaps a simple round-robin > > agent). In this case, I would like the client to only use the LOCATION_FORWARD > > ior once, getting a new one on each invocation. But there is currently > > no standard way to get such behavior. > > Yes. But, I think that particular issue is not related to > LOCATION_FORWARD_PERM (only to LOCATION_FORWARD), so I think we should address > this as part of a separate issue. (Many ORBs already have proprietary > configuration mechanisms to permit tinkering with the client-side binding > algorithms.) > > > It seems to me that all we can specify is what happens on subsequent invocations > > on the same object reference, so long as the ORB instance that created > > the object reference continues to exist. > > I'm not sure I understand what you mean by this. Can you elaborate? > As far as I am concerned, a LOCATION_FORWARD_PERM simply overwrites > or replaces all knowledge about the previous IOR/proxy. I think that's > pretty much all that needs to be said. > > > > - In order to make hash() behave sensibly, we would need to > > > specify the hashing algorithm *for FT IORs only*. The hash > > > value could be computed from the group ID in some way. > > > > > >The drift of all this is to put permanent forwarding back into the core, > > >but only for FT IORs. I think this could work because it would meet the > > >needs of FT without making a mess of what's there already. > > > > > > > This requires then that we move the IOGR definition (and perhaps a fair > > bit of FT chapter 5) into the core. Is this what we want to do here? > > Do we want the different possible behaviors of location forwards to be > > tied directly to the needs of a particular specification like FT? > > The idea to restrict permanent forwarding to FT was motivated by the > problems we ran into in the core. In particular, there is no sensible > way to keep the requirement for hash() to return an immutable value > in the presence for (general) permanent forwarding. That's why we > removed LOCATION_FORWARD_PERM again. But the FT people need it. So, > as a compromise, the idea was to restrict the feature to FT only. For > FT, we can avoid the hash() problem by defining the algorithm that's used > to compute the hash value from the group ID. That ensures that, for all > ORBs, and FT IOR has the same hash value regardless of how many times it > was forwarded. > > 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 un.COM>, jmischki@wheel.dcn.davis.ca.us, interop@omg.org, orb_revision@omg.org Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut In-Reply-To: Your message of "Tue, 24 Oct 2000 05:49:31 PDT." <39F5855B.CBC3ACF5@iona.com> From: Bill Janssen Message-Id: <00Oct24.074858pdt."3441"@watson.parc.xerox.com> Date: Tue, 24 Oct 2000 07:48:52 PDT Content-Type: text X-UIDL: 1g/!!#*5!!%mX!!Cj$!! > Also, I thought the main issue with LFP was not the hash problem, but > the fact that CORBA provided no mechanism to inform the application that > a reference stored persistently needed to be updated. Is this still a > concern? In my opinion, this is exactly the issue. Without providing some such mechanism, it doesn't really make sense to have LOCATION_FORWARD_PERM. It's not just the ORB that has to be notified; every piece of application code that's stored away a reference, whether it's a dependency on the value of hash(), or a stringified IOR, has to have a chance to update its storage. Bill From: "Rutt, T E (Tom)" To: "M. Mortazavi" , "'Jishnu Mukerji'" Cc: Jeffrey Mischkinsky , "'Michi Henning'" , Interoperability RTF , Core Revision Task Force Subject: RE: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut Date: Tue, 24 Oct 2000 13:26:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-UIDL: b*a!!5V[d9-I0e9MQB!! ter ---------- From: Jishnu Mukerji [SMTP:jis@fpk.hp.com] Sent: Monday, October 23, 2000 11:43 AM To: M. Mortazavi Cc: Rutt, T E (Tom); Jeffrey Mischkinsky; 'Michi Henning'; Interoperability RTF; Core Revision Task Force Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut "M. Mortazavi" wrote: > > a "forward-only" update of IOR(IOGR) is necessary for FT > > > > > > > - FT references are identifiable by their components, so we > > can restrict permanent forwarding to FT references *only*. > > > > - When an FT reference is permanently forwarded, the ORB > > receiving > > the forward replaces the original IOR with the new one and > > forgets everything about the original IOR. > > i.e. "forward-only" > > > - In order to make hash() behave sensibly, we would need to > > specify the hashing algorithm *for FT IORs only*. The hash > > value could be computed from the group ID in some way. > > some FT people suggested this, as well. > while this'll work, since this is only for FT, wouldn't it be better to see--now > that it or something like it will go back in--whether they would have liked to > see something a bit more suitable, or more general. For example, an IOR Update > reply message with a field that gives some data structure for the mode of the > IOR update, could be very useful, much more useful than a location forward > permanent. If there's an IOR update message, let's make it somewhat more > general. Some modes of update (such as "permanent or forward-only") could be > part of the specifications. I think this might be an approach worth exploring. The conservative in me says that this sort of on the fly feturelet additions through RTFs should be discouraged, so I will tend to vote against this sort of thing. It is not just a matter of adding another message, but also figuring out what the recipient of the message is to do with it, not just in the FT space, but affecting all general purpose ORBs in potentially backward incompatible ways. We are yet to completely figure out what to do with a simple LOCATION_FORWARD_PERM. Lets get that done addressing the immediate issue that the FT spec has, and leave other fancy enhancements for future RFPs. Jishnu. I tend to agree with Jishnu. My take, from an admin standpoint, is that the Interop RTF has Depreciated the use of location forward perm for two reasons: 1) the impact on Hash lifetime 2) the signaling to the client application that all stored reference must be refreshed This issue is closed in interop rtf, however the FT FTF has concerns that Location forward perm is needed. It is thus their responsibility to come up with solutions two the two problems (at least Within the scope of FT group IORs) as part of resolving their FTF issue. Tom Rutt Terutt@Lucent.com -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com Date: Tue, 24 Oct 2000 13:59:57 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kukura Cc: Michi Henning , Ken Cavanaugh , jmischki@wheel.dcn.davis.ca.us, interop@omg.org, orb_revision@omg.org Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut References: <39F5855B.CBC3ACF5@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: gVW!!9+kd9(`]d9^Og!! Bob Kukura wrote: > > I've been traveling and away from email the since last Thursday, and > haven't completely caught up on this thread. But I thought I'd state my > position on this issue. > > I don't think its the lifespan of LOCATION_FORWARD_PERM thats the > problem - its the lifespan of the hash function. All the ORBs I've > worked on treat the lifespan of the hash result as bounded by the > lifetime of the reference within the process. If another process calls > hash on a reference, its likely to get a different hash value. This is > adequate for in-memory hash tables, and as far as I am aware, is all > that is currently required by the specification. No customers have > complained. That is a good point. > But I admit this isn't the only way to interpret the spec. > So my position is that all we need to do is clarify that this how > hash > may behave, and then we don't need to worry about location forward > permanent changing the hash result when the forwarded IOR is sent to > a > different process. The original process can keep both around, and > ensure > that the hash value from the original IOR is returned. I am opposed > to > any attempt to make the core aware of a distinction between "FT" and > "normal" IORs. Interesting. So how will the core know that it needs to do a different thing with an invocation using an FT IOR, as opposed to a normal one? > Also, I thought the main issue with LFP was not the hash problem, but > the fact that CORBA provided no mechanism to inform the application that > a reference stored persistently needed to be updated. Is this still a > concern? That apparently is not a big issue with the FT folks, as far as I could gather. I would also like to point out, that for some reason this issue is being discussed only in the interop and orb_revision RTF, and is not being discussed on the ft-ftf list. It is FT-FTF that owns this issue, and it is in FT-FTF it is going to get resolved, not in Core RTF or Interop RTF. There is no issue in Core at present, and the Interop issue was closed by deprecating LFP. Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com From: "Rutt, T E (Tom)" To: "'Juergen Boldt'" Subject: RE: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut Date: Tue, 24 Oct 2000 16:21:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Ea+e9W!Od9:U$!!'#6e9 Raise it as an FTF issue for Fault Tolerance. Their spec uses the LocateForwarePerm, but it has been deprecated In core. This is the issue. Tom Rutt ter ---------- From: Juergen Boldt [SMTP:juergen@omg.org] Sent: Tuesday, October 24, 2000 4:22 PM To: Rutt, T E (Tom); jis@fpk.hp.com; Bob Kukura Cc: Michi Henning; Ken Cavanaugh; jmischki@wheel.dcn.davis.ca.us; interop@omg.org; orb_revision@omg.org; ft-ftf@emerald.omg.org Subject: RE: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut looking for a home for this issue...comments? -Juergen At 04:10 PM 10/24/00 -0400, Rutt, T E (Tom) wrote: >Juergen > >This is not an interop issue. > >It was closed as an old interop issue. > >The only issue is an FTF issue. Please do not make a new interop issue. > >Tom Rutt >ter > > ---------- > From: Juergen Boldt [SMTP:juergen@omg.org] > Sent: Tuesday, October 24, 2000 2:58 PM > To: jis@fpk.hp.com; Bob Kukura > Cc: Michi Henning; Ken Cavanaugh; jmischki@wheel.dcn.davis.ca.us; >interop@omg.org; orb_revision@omg.org; ft-ftf@emerald.omg.org > Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM >for Faut > > This issue is currently logged under interop with the issue number >3976. > > -Juergen > > > At 01:59 PM 10/24/00 -0400, Jishnu Mukerji wrote: > >Bob Kukura wrote: > > > > > > I've been traveling and away from email the since last Thursday, >and > > > haven't completely caught up on this thread. But I thought I'd >state my > > > position on this issue. > > > > > > I don't think its the lifespan of LOCATION_FORWARD_PERM thats >the > > > problem - its the lifespan of the hash function. All the ORBs >I've > > > worked on treat the lifespan of the hash result as bounded by >the > > > lifetime of the reference within the process. If another >process calls > > > hash on a reference, its likely to get a different hash value. >This is > > > adequate for in-memory hash tables, and as far as I am aware, is >all > > > that is currently required by the specification. No customers >have > > > complained. > > > >That is a good point. > > > > > But I admit this isn't the only way to interpret the spec. > > > So my position is that all we need to do is clarify that this >how hash > > > may behave, and then we don't need to worry about location >forward > > > permanent changing the hash result when the forwarded IOR is >sent to a > > > different process. The original process can keep both around, >and ensure > > > that the hash value from the original IOR is returned. I am >opposed to > > > any attempt to make the core aware of a distinction between "FT" >and > > > "normal" IORs. > > > >Interesting. So how will the core know that it needs to do a >different > >thing with an invocation using an FT IOR, as opposed to a normal >one? > > > > > Also, I thought the main issue with LFP was not the hash >problem, but > > > the fact that CORBA provided no mechanism to inform the >application that > > > a reference stored persistently needed to be updated. Is this >still a > > > concern? > > > >That apparently is not a big issue with the FT folks, as far as I >could > >gather. > > > >I would also like to point out, that for some reason this issue is >being > >discussed only in the interop and orb_revision RTF, and is not >being > >discussed on the ft-ftf list. It is FT-FTF that owns this issue, >and it > >is in FT-FTF it is going to get resolved, not in Core RTF or >Interop > >RTF. There is no issue in Core at present, and the Interop issue >was > >closed by deprecating LFP. > > > >Jishnu. > > > >-- > >Jishnu Mukerji > >Senior Systems Architect, EIAL > >Hewlett-Packard Company > >300 Campus Drive, MS 2E-62 > >Florham Park NJ 07932, USA > >+1 973 443 7528 > >jis@fpk.hp.com > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > > > > ================================================================ ================================================================ Juergen Boldt Senior Member of Technical Staff Object Management Group Tel. +1-781 444 0404 ext. 132 250 First Avenue, Suite 201 Fax: +1-781 444 0320 Needham, MA 02494, USA Email: juergen@omg.org ================================================================ Date: Tue, 24 Oct 2000 16:13:25 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Boldt Cc: Bob Kukura , Michi Henning , Ken Cavanaugh , jmischki@wheel.dcn.davis.ca.us, interop@omg.org, orb_revision@omg.org, ft-ftf@emerald.omg.org Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM forFaut References: <39F5855B.CBC3ACF5@iona.com> <4.2.0.58.20001024145558.00a92660@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 1`ld9VDT!!$Rhd9IFB!! Juergen Boldt wrote: > > This issue is currently logged under interop with the issue number 3976. > > -Juergen It should not be. It should be logged with FTFTF since they have to come up with what they need. After they have specified what they need and resolved in that FTF then any fallout from that will need to be dealt with elsewhere. As an FTF they have more leeway to propose changes than any old RTF has. The reason that Julien raised this question in interop and core is in order to tap in to the expertise that is available in these groups to come up with an acceptable resolution to vote on in FTFTF. At least that is my understnading of what was discussed on this matter in Burlingame. Jishnu. > At 01:59 PM 10/24/00 -0400, Jishnu Mukerji wrote: > >Bob Kukura wrote: > > > > > > I've been traveling and away from email the since last Thursday, and > > > haven't completely caught up on this thread. But I thought I'd state my > > > position on this issue. > > > > > > I don't think its the lifespan of LOCATION_FORWARD_PERM thats the > > > problem - its the lifespan of the hash function. All the ORBs I've > > > worked on treat the lifespan of the hash result as bounded by the > > > lifetime of the reference within the process. If another process calls > > > hash on a reference, its likely to get a different hash value. This is > > > adequate for in-memory hash tables, and as far as I am aware, is all > > > that is currently required by the specification. No customers have > > > complained. > > > >That is a good point. > > > > > But I admit this isn't the only way to interpret the spec. > > > So my position is that all we need to do is clarify that this how hash > > > may behave, and then we don't need to worry about location forward > > > permanent changing the hash result when the forwarded IOR is sent to a > > > different process. The original process can keep both around, and ensure > > > that the hash value from the original IOR is returned. I am opposed to > > > any attempt to make the core aware of a distinction between "FT" and > > > "normal" IORs. > > > >Interesting. So how will the core know that it needs to do a different > >thing with an invocation using an FT IOR, as opposed to a normal one? > > > > > Also, I thought the main issue with LFP was not the hash problem, but > > > the fact that CORBA provided no mechanism to inform the application that > > > a reference stored persistently needed to be updated. Is this still a > > > concern? > > > >That apparently is not a big issue with the FT folks, as far as I could > >gather. > > > >I would also like to point out, that for some reason this issue is being > >discussed only in the interop and orb_revision RTF, and is not being > >discussed on the ft-ftf list. It is FT-FTF that owns this issue, and it > >is in FT-FTF it is going to get resolved, not in Core RTF or Interop > >RTF. There is no issue in Core at present, and the Interop issue was > >closed by deprecating LFP. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com From: "Rutt, T E (Tom)" To: Bob Kukura , "'Jishnu Mukerji'" Cc: Michi Henning , Ken Cavanaugh , jmischki@wheel.dcn.davis.ca.us, interop@omg.org, orb_revision@omg.org, "'ft-ftf@omg.org'" Subject: RE: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut Date: Tue, 24 Oct 2000 15:58:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-UIDL: _Z*e9S9Qe9B]fd9-T^!! ---------- From: Jishnu Mukerji [SMTP:jis@fpk.hp.com] Sent: Tuesday, October 24, 2000 2:00 PM To: Bob Kukura Cc: Michi Henning; Ken Cavanaugh; jmischki@wheel.dcn.davis.ca.us; interop@omg.org; orb_revision@omg.org Subject: Re: Issue of harmful deprecation of LOCATE_FORWARD_PERM for Faut Bob Kukura wrote: > > Also, I thought the main issue with LFP was not the hash problem, but > the fact that CORBA provided no mechanism to inform the application that > a reference stored persistently needed to be updated. Is this still a > concern? That apparently is not a big issue with the FT folks, as far as I could gather. I am not so sure. They also have this problem, but were not aware of it at The last meeting. I agree that the ft-ftf must be the resolver (if anyone). Tom Rutt I would also like to point out, that for some reason this issue is being discussed only in the interop and orb_revision RTF, and is not being discussed on the ft-ftf list. It is FT-FTF that owns this issue, and it is in FT-FTF it is going to get resolved, not in Core RTF or Interop RTF. There is no issue in Core at present, and the Interop issue was closed by deprecating LFP. Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com Date: Tue, 24 Oct 2000 14:37:11 -0700 (PDT) Message-Id: <200010242137.OAA03485@iota.ece.ucsb.edu> X-Authentication-Warning: iota.ece.ucsb.edu: moser set sender to moser@alpha.ece.ucsb.edu using -f From: Louise Moser To: ft-ftf@omg.org Subject: LOCATE_FORWARD_PERM - Issue 3976 Reply-to: moser@ece.ucsb.edu Content-Type: text X-UIDL: KL4!!ijpd9)?nd9!aAe9 Hello, Here are Julien's ideas on the LOCATE_FORWARD_PERM issue. See the rest of his message at http://cgi.omg.org/issues/ft-ftf.html#Issue3976. If you would like to refine his proposal or to make an alternate proposal, please send a message to the FTFTF. Thanks. Louise ====================================================================== Issue of scope: The scope of LOCATE_FORWARD_PERM is ORB lifetime. Issue of hash() : The Fault-Tolerant CORBA specification defines the concept of an Interoperable Object Group Reference (IOGR). The IOGR contains a specific profile that contains an object group identifier. When an ORB receives an IOGR, it should compute the value of hash() based on the object group identifier contained in the IOGR, and perform LOCATE_FORWARD_PERMs if requested. When an ORB receives a normal IOR (i.e. an IOR lacking a group profile) it should compute hash() in the customary manner, and does not need to respond to LOCATE_FORWARD_PERMs. Date: Wed, 1 Nov 2000 20:19:18 -0800 (PST) Message-Id: <200011020419.UAA12446@iota.ece.ucsb.edu> X-Authentication-Warning: iota.ece.ucsb.edu: moser set sender to moser@alpha.ece.ucsb.edu using -f From: Louise Moser To: ft-ftf@omg.org, issues@omg.org, juergen@omg.org Subject: Voting on Issues 3747, 3908, 3976 Reply-to: moser@ece.ucsb.edu Content-Type: text X-UIDL: P**!!Wa'e9"A?!!7bLe9 Hello Everyone, Here are Issues 3747, 3908, 3976 with more precise editing instructions. If anyone has any refinements of the proposed resolutions, please email us your refinements by Friday, November 3. Otherwise, we will commence voting on these issues with the polls closing on Friday, November 10. Thanks. Louise ======================================================================= ISSUE 3747 YES NO ABSTAIN The adopted draft specification defines State as a sequence. This presents a problem when coding get_state() and set_state() for an application whose state contains an any. To marshal an any into a sequence of octet, the application must contain routines comparable in size and complexity to those of a complete ORB. The Replication Manager itself contains any values and is such an application. It has been suggested that the State be defined as an any. The marshalling of any is, however, inefficient in processing time and message size. The simplest of the proposed compromises defines State as a struct that contains both a sequence and an any. This would allow a user to transfer state using either the sequence or the any or both. Proposed Resolution: Replace the definition of State in Section 27.5.4 on pages 27-84 and 27-85 and in Appendix A Consolidated IDL on page 27-102 by struct State { sequence octet_val; any any_val; }; ======================================================================= ISSUE 3908 YES NO ABSTAIN 13.6.7 of the CORBA 2.3 specification states: "The context data for a particular service will be encoded as specified for its service-specific OMG IDL definition, and that encoded representation will be encapsulated in the context_data member of IOP::ServiceContext. (See Section 15.3.3, Encapsulation, on page 15-13)." The descriptions of service contexts in the FT specification are missing an explicit statement of the encoding of the service context data. Proposed Resolution: Replace the first sentence of Section 27.2.7.1 on page 27-22 by the following two sentences: "The FTGroupVersionServiceContext struct contains the version of the object group reference for the server object group, which allows the server to determine whether the client is using an obsolete object group reference. When encoded in a request or reply message header, the context_data component of the ServiceContext struct shall contain a CDR encapsulation of the FTGroupVersionServiceContext struct, which is defined below." Replace the first sentence of Section 27.2.8.1 on page 27-24 by the following two sentences: "The FTRequestServiceContext is used to ensure that a request is not executed more than once under fault conditions. When encoded in a request or reply message header, the context_data component of the ServiceContext struct shall contain a CDR encapsulation of the FTRequestServiceContext struct, which is defined below." ======================================================================= ISSUE 3976 YES NO ABSTAIN Earlier this year, the Interop FTF deprecated the LOCATION_FORWARD_PERM exception because it was poorly specified and made implementation of hash() difficult. However, for Fault Tolerant CORBA, the LOCATION_FORWARD_PERM exception is essential. Proposed Resolution: In Section 27.2.5, immediately before 27.2.5.1, insert the following paragraph: "The first of these three options, access directly to a member of a server object group, requires the use of the LOCATION_FORWARD_PERM exception. As object replicas fail and are replaced by new replicas, a stage may be reached at which all of the original replicas, cited in the original interoperable object group reference for the object, are inaccessible. Continued use of the original reference will cause system failure. The LOCATION_FORWARD_PERM exception allows such a reference to be replaced by an updated reference that contains profiles for the new replacement replicas. Thus, the LOCATION_FORWARD_PERM exception is not deprecated when it is used to return an interoperable object group reference. The use of the LOCATION_FORWARD_PERM exception to return a reference that is not an interoperable object group reference continues to be deprecated." In Section 27.2.6, after the first paragraph on page 27-21, insert the following paragraph: "The temporal scope of the replacement reference provided by LOCATION_FORWARD_PERM is ORB lifetime or the next LOCATION_FORWARD_PERM. It is safe, and appropriate, for an ORB to replace any reference that contains the same fault tolerance domain identifier, the same object group identifier and a smaller value of the version of the object group reference." In Section 27.2.3.6 on page 27-18, replace "Follows the semantics above." by "Follows the semantics for is_equivalent(). An interoperable object group reference contains an object group identifier that is unique and immutable over the lifetime of the object group. For such a reference, the value of hash() shall be derived from the object group identifier. For references that are not interoperable object group references, the value of hash() continues to be derived as at present." Sender: Chris.Smith@uab.ericsson.se Message-ID: <3A0174A3.9A6749E7@uab.ericsson.se> Date: Thu, 02 Nov 2000 15:05:23 +0100 From: Chris Smith X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: moser@ece.ucsb.edu CC: ft-ftf@omg.org, juergen@omg.org Subject: Re: Voting on Issues 3747, 3908, 3976 References: <200011020419.UAA12446@iota.ece.ucsb.edu> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Pp ISSUE 3747 YES NO ABSTAIN > > The adopted draft specification defines State as a sequence. > This presents a problem when coding get_state() and set_state() for > an > application whose state contains an any. To marshal an any into a > sequence of octet, the application must contain routines comparable > in > size and complexity to those of a complete ORB. The Replication > Manager > itself contains any values and is such an application. > > It has been suggested that the State be defined as an any. The > marshalling of any is, however, inefficient in processing time and > message size. > > The simplest of the proposed compromises defines State as a struct > that > contains both a sequence and an any. This would allow a user > to transfer state using either the sequence or the any or > both. > > Proposed Resolution: > > Replace the definition of State in Section 27.5.4 on pages 27-84 > and > 27-85 and in Appendix A Consolidated IDL on page 27-102 by > > struct State > { > sequence octet_val; > any any_val; > }; > > ======================================================================= > > ISSUE 3908 YES NO ABSTAIN > > 13.6.7 of the CORBA 2.3 specification states: "The context data for > a > particular service will be encoded as specified for its > service-specific > OMG IDL definition, and that encoded representation will be > encapsulated > in the context_data member of IOP::ServiceContext. (See Section > 15.3.3, > Encapsulation, on page 15-13)." The descriptions of service contexts > in > the FT specification are missing an explicit statement of the > encoding > of the service context data. > > Proposed Resolution: > > Replace the first sentence of Section 27.2.7.1 on page 27-22 by > the following two sentences: > > "The FTGroupVersionServiceContext struct contains the version > of > the object group reference for the server object group, which > allows the server to determine whether the client is using an > obsolete object group reference. When encoded in a request or > reply > message header, the context_data component of the > ServiceContext > struct shall contain a CDR encapsulation of the > FTGroupVersionServiceContext struct, which is defined below." > > Replace the first sentence of Section 27.2.8.1 on page 27-24 by > the following two sentences: > > "The FTRequestServiceContext is used to ensure that a request > is > not executed more than once under fault conditions. When > encoded > in a request or reply message header, the context_data > component of > the ServiceContext struct shall contain a CDR encapsulation of > the > FTRequestServiceContext struct, which is defined below." > > ======================================================================= > > ISSUE 3976 YES NO ABSTAIN > > Earlier this year, the Interop FTF deprecated the > LOCATION_FORWARD_PERM > exception because it was poorly specified and made implementation of > hash() difficult. However, for Fault Tolerant CORBA, the > LOCATION_FORWARD_PERM exception is essential. > > Proposed Resolution: > > In Section 27.2.5, immediately before 27.2.5.1, insert the following > paragraph: > > "The first of these three options, access directly to a member > of a > server object group, requires the use of the > LOCATION_FORWARD_PERM > exception. As object replicas fail and are replaced by new > replicas, a stage may be reached at which all of the original > replicas, cited in the original interoperable object group > reference for the object, are inaccessible. Continued use of > the > original reference will cause system failure. The > LOCATION_FORWARD_PERM exception allows such a reference to be > replaced by an updated reference that contains profiles for the > new > replacement replicas. Thus, the LOCATION_FORWARD_PERM > exception is > not deprecated when it is used to return an interoperable > object > group reference. The use of the LOCATION_FORWARD_PERM > exception to > return a reference that is not an interoperable object group > reference continues to be deprecated." > > In Section 27.2.6, after the first paragraph on page 27-21, insert > the > following paragraph: > > "The temporal scope of the replacement reference provided by > LOCATION_FORWARD_PERM is ORB lifetime or the next > LOCATION_FORWARD_PERM. It is safe, and appropriate, for an ORB > to > replace any reference that contains the same fault tolerance > domain > identifier, the same object group identifier and a smaller > value of > the version of the object group reference." > > In Section 27.2.3.6 on page 27-18, replace "Follows the semantics > above." by > > "Follows the semantics for is_equivalent(). An interoperable > object group reference contains an object group identifier that > is > unique and immutable over the lifetime of the object group. > For > such a reference, the value of hash() shall be derived from the > object group identifier. For references that are not > interoperable > object group references, the value of hash() continues to be > derived as at present." From: "Rutt, T E (Tom)" To: moser@ece.ucsb.edu, "'Jishnu Mukerji'" Cc: ft-ftf@omg.org, orb_revision@omg.org, interop@omg.org Subject: RE: Voting on Issues 3747, 3908, 3976 Date: Thu, 2 Nov 2000 13:06:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: :O%!!P&+e9!&%"!-ccd9 Does this solution address how the Client application is made aware that an old reference It has must be replaced? Tom rutt ter ---------- From: Jishnu Mukerji [SMTP:jis@fpk.hp.com] Sent: Thursday, November 02, 2000 11:17 AM To: moser@ece.ucsb.edu Cc: ft-ftf@omg.org; orb_revision@omg.org; interop@omg.org Subject: Re: Voting on Issues 3747, 3908, 3976 Louise Moser wrote: > > Hello Everyone, > > Here are Issues 3747, 3908, 3976 with more precise editing instructions. > If anyone has any refinements of the proposed resolutions, please email > us your refinements by Friday, November 3. Otherwise, we will commence > voting on these issues with the polls closing on Friday, November 10. > > Thanks. > > Louise > > ======================================================================= > . . . . . . . > > ISSUE 3976 YES NO ABSTAIN > > Earlier this year, the Interop FTF deprecated the LOCATION_FORWARD_PERM > exception because it was poorly specified and made > implementation of > hash() difficult. However, for Fault Tolerant CORBA, the > LOCATION_FORWARD_PERM exception is essential. > > Proposed Resolution: > > In Section 27.2.5, immediately before 27.2.5.1, insert the following > paragraph: > > "The first of these three options, access directly to a member of a > server object group, requires the use of the LOCATION_FORWARD_PERM > exception. As object replicas fail and are replaced by > new > replicas, a stage may be reached at which all of the > original > replicas, cited in the original interoperable object > group > reference for the object, are inaccessible. Continued > use of the > original reference will cause system failure. The > LOCATION_FORWARD_PERM exception allows such a reference > to be > replaced by an updated reference that contains profiles > for the new > replacement replicas. Thus, the LOCATION_FORWARD_PERM exception is > not deprecated when it is used to return an > interoperable object > group reference. The use of the LOCATION_FORWARD_PERM exception to > return a reference that is not an interoperable > object group > reference continues to be deprecated." > > In Section 27.2.6, after the first paragraph on page 27-21, > insert the > following paragraph: > > "The temporal scope of the replacement reference > provided by > LOCATION_FORWARD_PERM is ORB lifetime or the next > LOCATION_FORWARD_PERM. It is safe, and appropriate, > for an ORB to > replace any reference that contains the same fault > tolerance domain > identifier, the same object group identifier and a > smaller value of > the version of the object group reference." > > In Section 27.2.3.6 on page 27-18, replace "Follows the > semantics > above." by > > "Follows the semantics for is_equivalent(). An > interoperable > object group reference contains an object group > identifier that is > unique and immutable over the lifetime of the object > group. For > such a reference, the value of hash() shall be derived > from the > object group identifier. For references that are not interoperable > object group references, the value of hash() continues > to be > derived as at present." Louise, In addition to changes in Chapter 27, these modifications also need to be reflected in Chapters 4 and 15 (I think). The best way to handle this is for you to propose additions to these chapters based on the draft CORBA Core 2.4 as it appears in orbrev/00-09-01, and then have the Core RTF and the Interop RTF review them before they are approved for inclusion in those chapters. So as a starter please propose these additions to the existing Core chapter to the FT FTF and get them approved there and then send them over to the Core and Interop RTFs for final action, just to help us all maintain our editorial sanity.:-) Thanks, Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com Date: Thu, 2 Nov 2000 14:32:09 -0800 (PST) Message-Id: <200011022232.OAA13012@iota.ece.ucsb.edu> X-Authentication-Warning: iota.ece.ucsb.edu: moser set sender to moser@alpha.ece.ucsb.edu using -f From: Louise Moser To: terutt@lucent.com Subject: Re: Issue 3976 Reply-to: moser@ece.ucsb.edu Cc: ft-ftf@omg.org, orb_revision@omg.org, interop@omg.org Content-Type: text X-UIDL: ,SQd9~+Wd90F[!!G3ad9 Tom, Thanks for your feedback. >Does this solution address how the Client application is made aware that an >old reference >It has must be replaced? The FT CORBA specification, and the proposed resolution, does not address this issue. The mechanisms for updating references at clients is a "pull" mechanism, triggered either by an attempt to use the reference or, alternatively, by an explicit request for the latest version of a reference. No "push to the client" mechanism is provided. Thanks. Louise Date: Thu, 2 Nov 2000 14:26:21 -0800 (PST) Message-Id: <200011022226.OAA13009@iota.ece.ucsb.edu> X-Authentication-Warning: iota.ece.ucsb.edu: moser set sender to moser@alpha.ece.ucsb.edu using -f From: Louise Moser To: jis@fpk.hp.com In-reply-to: <3A01937B.A096BF6E@fpk.hp.com> (message from Jishnu Mukerji on Thu, 02 Nov 2000 11:16:59 -0500) Subject: Re: Voting on Issues 3747, 3908, 3976 Reply-to: moser@ece.ucsb.edu Cc: ft-ftf@omg.org Content-Type: text X-UIDL: nP/!!?,gd9TCcd9c;Sd9 Jishnu, Thanks for your feedback. >inclusion in those chapters. So as a starter please propose these >additions to the existing Core chapter to the FT FTF and get them >approved there and then send them over to the Core and Interop RTFs >for >final action, just to help us all maintain our editorial sanity.:-) I will try to get a proposal together on the existing Core Chapters by tomorrow. Thanks. Louise Date: Thu, 2 Nov 2000 19:38:16 -0330 From: Matthew Newhook To: moser@ece.ucsb.edu Cc: terutt@lucent.com, ft-ftf@omg.org, orb_revision@omg.org, interop@omg.org Subject: Re: Issue 3976 Message-ID: <20001102193816.C31065@ooc.com> References: <200011022232.OAA13012@iota.ece.ucsb.edu> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <200011022232.OAA13012@iota.ece.ucsb.edu> Content-Type: text/plain; charset=us-ascii X-UIDL: W>l!!2EKe9B(`d9*D?!! Hi, On Thu, Nov 02, 2000 at 02:32:09PM -0800, Louise Moser wrote: > > Tom, > > Thanks for your feedback. > > >Does this solution address how the Client application is made aware that an > >old reference > >It has must be replaced? > > The FT CORBA specification, and the proposed resolution, does not > address this issue. The mechanisms for updating references at clients > is a "pull" mechanism, triggered either by an attempt to use the > reference or, alternatively, by an explicit request for the latest > version of a reference. No "push to the client" mechanism is provided. Sorry, that doesn't help. The client simply by using the object reference cannot know that the location of the object has changed (ie: it doesn't know about location forwards, and all that good stuff) (unless of course the client has turned off automatic rebinding). > Thanks. > > Louise 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, 2 Nov 2000 19:11:22 -0800 (PST) Message-Id: <200011030311.TAA13305@iota.ece.ucsb.edu> X-Authentication-Warning: iota.ece.ucsb.edu: moser set sender to moser@alpha.ece.ucsb.edu using -f From: Louise Moser To: matthew@ooc.com In-reply-to: <20001102193816.C31065@ooc.com> (message from Matthew Newhook on Thu, 2 Nov 2000 19:38:16 -0330) Subject: Re: Issue 3976 Cc: terutt@lucent.com, ft-ftf@omg.org, orb_revision@omg.org, interop@omg.org Content-Type: text X-UIDL: ",$!!WoDe9IgTd9:Na!! Hi Matthew: Thank you for your comment. > Sorry, that doesn't help. The client simply by using the object reference > cannot know that the location of the object has changed (ie: it doesn't > know about location forwards, and all that good stuff) (unless of course > the client has turned off automatic rebinding). If the client waits so long between using its copy of the object group reference that every profile in the reference has become obsolete, when the client does invoke a method using the obsolete object group reference, the client ORB must return an exception to the client and the client can obtain a new reference to the server, either from a Name Service or from the Replication Manager. If, however, any one of the profiles is still valid, the Fault Tolerant CORBA specification allows the LOCATION_FORWARD_PERM exception so that the client ORB can update its copy of the object group reference. This reduces the probability that the reference will become completely obsolete but cannot completely eliminate that risk. It might be possible to devise a mechanism that tracks outstanding references that are held by clients, so that they can be updated automatically. Such a mechanism could never be complete, because of stringified references written on postcards, etc. The submitters did not propose such a mechanism. Thanks. Louise Date: Fri, 3 Nov 2000 00:44:41 -0330 From: Matthew Newhook To: Louise Moser Cc: terutt@lucent.com, ft-ftf@omg.org, orb_revision@omg.org, interop@omg.org Subject: Re: Issue 3976 Message-ID: <20001103004441.B5461@ooc.com> References: <20001102193816.C31065@ooc.com> <200011030311.TAA13305@iota.ece.ucsb.edu> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <200011030311.TAA13305@iota.ece.ucsb.edu> Content-Type: text/plain; charset=us-ascii X-UIDL: `S#e9Ead!!0F0!!8'd!! Hi, On Thu, Nov 02, 2000 at 07:11:22PM -0800, Louise Moser wrote: > [...] > If the client waits so long between using its copy of the object group > reference that every profile in the reference has become obsolete, when > the client does invoke a method using the obsolete object group > reference, the client ORB must return an exception to the client and the > client can obtain a new reference to the server, either from a Name > Service or from the Replication Manager. If, however, any one of the > profiles is still valid, the Fault Tolerant CORBA specification allows > the LOCATION_FORWARD_PERM exception so that the client ORB can update > its copy of the object group reference. Why doesn't the original reference point to a group reference manager -- similar to an implementation repository? In this way LOCATION_FORWARD_PERM isn't necessary (assuming that the manager isn't moved, of course). However, I don't consider that to be a typical problem, and so therefore not a showstopper. After all even if the manager is moved what good is location forward perm? Something has to be present to forward the request... > This reduces the probability > that the reference will become completely obsolete but cannot > completely > eliminate that risk. Right, the manager eliminates the risk -- and the CORBA spec doesn't need to be changed, nothing needs to be added. This is a well known problem, with a well established well implemented solution. ORBs have been doing this for years. > It might be possible to devise a mechanism that tracks outstanding > references that are held by clients, so that they can be updated > automatically. Such a mechanism could never be complete, because of > stringified references written on postcards, etc. The submitters > did > not propose such a mechanism. I also don't think that the LOCATION_FORWARD_PERM is necessary either for the above reasons. > Thanks. > > Louise 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: Fri, 3 Nov 2000 12:35:22 -0800 (PST) Message-Id: <200011032035.MAA13625@iota.ece.ucsb.edu> X-Authentication-Warning: iota.ece.ucsb.edu: moser set sender to moser@alpha.ece.ucsb.edu using -f From: Louise Moser To: jis@fpk.hp.com, ft-ftf@omg.org, orb_revision@omg.org, interop@omg.org, juergen@omg.org Subject: Issue 3976 Reply-to: moser@ece.ucsb.edu Content-Type: text X-UIDL: aRPd9(O^d9=~7e9~_=!! Hello Everyone, The standard appears to define LOCATION_FORWARD_PERM but the Interop RTF refers to LOCATE_FORWARD_PERM. Jishnu, have we missed something or is this an error? Here is the Proposed Resolution of the LOCATION_FORWARD PERM Issue 3976, with changes to all of the relevant chapters (I hope). Thanks. Louise ========================================================================= ISSUE 3976 YES NO ABSTAIN Earlier this year, the Interop RTF deprecated the LOCATION_FORWARD_PERM exception because it was poorly specified and made implementation of hash() difficult. However, for Fault Tolerant CORBA, the LOCATION_FORWARD_PERM exception is essential. Proposed Resolution: 1. Add to the end of the first paragraph of Section 4.3.6.1 "For interoperable object group references, the identifier shall be the object group identifier which is not changed when the reference is updated by the LOCATION_FORWARD_PERM exception." 2. Change the following resolution of Interop RTF, which was to be included in Section 13.4.3.2 "Note: Usage of LOCATION_FORWARD_PERM is now deprecated, due to problems it causes with the semantics of the Object::hash() operation. LOCATION_FORWARD_PERM features could be removed from some future GIOP versions if solutions to these problems are not provided." to read "Note: Usage of LOCATION_FORWARD_PERM to return an object reference that is not an interoperable object group reference is now deprecated, due to problems it causes with the semantics of the Object::hash() operation." 3. Change the following resolution of Interop RTF, which was to be included in Section 13.4.6.1 "Note: Usage of LOCATION_FORWARD_PERM is now deprecated, due to problems it causes with the semantics of the Object::hash() operation. LOCATION_FORWARD_PERM features could be removed from some future GIOP versions if solutions to these problems are not provided." to read "Note: Usage of LOCATION_FORWARD_PERM to return an object reference that is not an interoperable object group reference is now deprecated, due to problems it causes with the semantics of the Object::hash() operation." 4. Change the following resolution of Interop RTF, which was to be included in Section 15.6 "Note: Usage of LOCATION_FORWARD_PERM and OBJECT_FORWARD_PERM is now deprecated, due to problems it causes with the semantics of the Object::hash() operation. LOCATION_FORWARD_PERM and OBJECT_FORWARD_PERM features could be removed from some future GIOP versions if solutions to these problems are not provided." to read "Note: Usage of LOCATION_FORWARD_PERM and OBJECT_FORWARD_PERM to return an object reference that is not an interoperable object group reference is now deprecated, due to problems it causes with the semantics of the Object::hash() operation." 5. In Section 27.2.5, immediately before 27.2.5.1, insert the following paragraph: "The first of these three options, access directly to a member of a server object group, requires the use of the LOCATION_FORWARD_PERM exception. As object replicas fail and are replaced by new replicas, a stage may be reached at which all of the original replicas, cited in the original interoperable object group reference for the object, are inaccessible. Continued use of the original reference will cause system failure. The LOCATION_FORWARD_PERM exception allows such a reference to be replaced by an updated reference that contains profiles for the new replacement replicas. Thus, the LOCATION_FORWARD_PERM exception is not deprecated when it is used to return an interoperable object group reference. The use of the LOCATION_FORWARD_PERM exception to return a reference that is not an interoperable object group reference continues to be deprecated." 6. In Section 27.2.6, after the first paragraph on page 27-21, insert the following paragraph: "The temporal scope of the replacement reference provided by LOCATION_FORWARD_PERM is ORB lifetime or the next LOCATION_FORWARD_PERM. It is safe, and appropriate, for an ORB to replace any reference that contains the same fault tolerance domain identifier, the same object group identifier and a smaller value of the version of the object group reference." 7. In Section 27.2.3.6 on page 27-18, replace "Follows the semantics above." by "Follows the semantics for is_equivalent(). An interoperable object group reference contains an object group identifier that is unique and immutable over the lifetime of the object group. For such a reference, the value of hash() shall be derived from the object group identifier. For references that are not interoperable object group references, the value of hash() continues to be derived as at present." Date: Fri, 3 Nov 2000 17:29:28 -0330 From: Matthew Newhook To: moser@ece.ucsb.edu Cc: jis@fpk.hp.com, ft-ftf@omg.org, orb_revision@omg.org, interop@omg.org, juergen@omg.org Subject: Re: Issue 3976 Message-ID: <20001103172928.B14683@ooc.com> References: <200011032035.MAA13625@iota.ece.ucsb.edu> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <200011032035.MAA13625@iota.ece.ucsb.edu> Content-Type: text/plain; charset=us-ascii X-UIDL: 4fF!!B'=e9\E'!!3(R!! Hi, On Fri, Nov 03, 2000 at 12:35:22PM -0800, Louise Moser wrote: > > Hello Everyone, > > The standard appears to define LOCATION_FORWARD_PERM but the Interop RTF > refers to LOCATE_FORWARD_PERM. Jishnu, have we missed something or is this an > error? > > Here is the Proposed Resolution of the LOCATION_FORWARD PERM Issue 3976, > with changes to all of the relevant chapters (I hope). > > Thanks. > > Louise > > ========================================================================= > > ISSUE 3976 YES NO ABSTAIN > > Earlier this year, the Interop RTF deprecated the LOCATION_FORWARD_PERM > exception because it was poorly specified and made implementation of > hash() difficult. However, for Fault Tolerant CORBA, the > LOCATION_FORWARD_PERM exception is essential. I am against this proposal. Currently I don't see a reason to add this to fault tolerant CORBA. As I said in a previous mail I for one don't think this is essential. You you review my previous mail on this topic and let me know why an approach based on the the implementation repository will not do? > [...] 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: Fri, 03 Nov 2000 16:19:38 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: moser@ece.ucsb.edu Cc: ft-ftf@omg.org, orb_revision@omg.org, interop@omg.org Subject: Re: Issue 3976 References: <200011032035.MAA13625@iota.ece.ucsb.edu> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: '<7e9M&9!!O_"!!'+4!! Louise Moser wrote: > > Hello Everyone, > > The standard appears to define LOCATION_FORWARD_PERM but the Interop RTF > refers to LOCATE_FORWARD_PERM. Jishnu, have we missed something or is this an > error? No, The Interop RTF was in error. Since then its error has been editorially fixed in the published (or soon to be published) text of CORBA Core 2.4. Regards, Jishnu. Date: Fri, 03 Nov 2000 16:52:45 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook Cc: moser@ece.ucsb.edu, ft-ftf@omg.org, orb_revision@omg.org, interop@omg.org Subject: Re: Issue 3976 References: <200011032035.MAA13625@iota.ece.ucsb.edu> <20001103172928.B14683@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: LDF!!"7E!!7$Sd9BB*e9 Matthew Newhook wrote: > > Hi, > > On Fri, Nov 03, 2000 at 12:35:22PM -0800, Louise Moser wrote: > > > > Hello Everyone, > > > > The standard appears to define LOCATION_FORWARD_PERM but the Interop RTF > > refers to LOCATE_FORWARD_PERM. Jishnu, have we missed something or is this an > > error? > > > > Here is the Proposed Resolution of the LOCATION_FORWARD PERM Issue 3976, > > with changes to all of the relevant chapters (I hope). > > > > Thanks. > > > > Louise > > > > ========================================================================= > > > > ISSUE 3976 YES NO ABSTAIN > > > > Earlier this year, the Interop RTF deprecated the LOCATION_FORWARD_PERM > > exception because it was poorly specified and made implementation of > > hash() difficult. However, for Fault Tolerant CORBA, the > > LOCATION_FORWARD_PERM exception is essential. > > I am against this proposal. Currently I don't see a reason to add this > to fault tolerant CORBA. > > As I said in a previous mail I for one don't think this is essential. You > you review my previous mail on this topic and let me know why an > approach based on the the implementation repository will not do? Matthew, Just to clarify the current situation, FT CORBA was adopted with this, to an extent implicitly, in the adopted spec, since when that spec was adopted LOCATION_FORWARD_PERM was a part of the Core. Actually it still is a part of the Core, but has been deprecated in the GIOP/IIOP portion of the spec. Therefore, I don't think it is a question of it being added by FT CORBA, It is already there. It was originally added by something else. FT CORBA used it and then we carelessly pulled the rug out from underneath them in the Interop RTF. The question is how to reconcile the deprecation in GIOP with the necessity of it in FT CORBA. The FT CORBA submitters in principle have a veto right to block removal of this feature from their adopted spec. I am personally not taking any position this way or that. I am just stating the current situation as it is. Regards, Jishnu. Date: Fri, 3 Nov 2000 14:09:49 -0800 (PST) Message-Id: <200011032209.OAA13671@iota.ece.ucsb.edu> X-Authentication-Warning: iota.ece.ucsb.edu: moser set sender to moser@alpha.ece.ucsb.edu using -f From: Louise Moser To: matthew@ooc.com In-reply-to: <20001103172928.B14683@ooc.com> (message from Matthew Newhook on Fri, 3 Nov 2000 17:29:28 -0330) Subject: Re: Issue 3976 Reply-to: moser@ece.ucsb.edu Cc: jis@fpk.hp.com, ft-ftf@omg.org, orb_revision@omg.org, interop@omg.org, juergen@omg.org Content-Type: text X-UIDL: I0g!!K&""!@=6e9S7*e9 Hi Matthew, >Currently I don't see a reason to add this to fault tolerant CORBA. We are not adding anything new to Fault Tolerant CORBA. We are only clarifying the semantics of LOCATION_FORWARD_PERM for Fault Tolerant CORBA. The adoption of the Fault Tolerant CORBA specification (with the use of LOCATION_FORWARD_PERM) and the deprecation of LOCATION_FORWARD_PERM by the Interop RTF happened asynchronously without communication between the two groups. > Why doesn't the original reference point to a group reference > manager -- similar to an implementation repository? In this way > LOCATION_FORWARD_PERM isn't necessary (assuming that the manager > isn't > moved, of course). However, I don't consider that to be a typical > problem, > and so therefore not a showstopper. After all even if the manager is > moved what good is location forward perm? Something has to be > present to > forward the request... Over a period of time, the processors that host the replicas of an object might fail and new replacement replicas might be created on other processors. If a client makes an invocation using a partially obsolete IOGR, it might fail to reach one or more of the replicas. If, however, even one of the profiles addresses an object replica on a working processor, the LOCATION_FORWARD_PERM exception can instruct the ORB at the client to update the client's copy of the IOGR with a version that includes profiles for the new replicas and excludes failed replicas. Provided that the client makes invocations more frequently than processors fail, the IOGR will continue to contain one or more profiles that the client can use to access the object. Constructing an IOGR whose profiles address the replicas of a group reference manager or implementation repository does not change the problem. The group reference manager must be a fault tolerant object, addressed by an IOGR with multiple profiles. The replicas of the group reference manager might fail and be replaced by new replicas on different processors. Thus, IOGR for the group reference manager might also need to be updated. If you really want a better grade of service based on pushing IOGR updates to the clients, we could provide an IOGR Updating Service. Each client would register each of its IOGRs with the IOGR Updating Service and the service would notify the client of each change to such an IOGR (of course, this means that the client cannot remain a pure client). The LOCATION_FORWARD_PERM provides almost as good a service but with much less intrusion into the client application. Thanks. Louise Date: Fri, 3 Nov 2000 21:13:22 -0330 From: Matthew Newhook To: moser@ece.ucsb.edu Cc: jis@fpk.hp.com, ft-ftf@omg.org, orb_revision@omg.org, interop@omg.org, juergen@omg.org Subject: Re: Issue 3976 Message-ID: <20001103211322.B16138@ooc.com> References: <20001103172928.B14683@ooc.com> <200011032209.OAA13671@iota.ece.ucsb.edu> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <200011032209.OAA13671@iota.ece.ucsb.edu> Content-Type: text/plain; charset=us-ascii X-UIDL: G9Ld9\KBe9d,(e942/e9 Hi Louise, On Fri, Nov 03, 2000 at 02:09:49PM -0800, Louise Moser wrote: > [...] > Over a period of time, the processors that host the replicas of an > object might fail and new replacement replicas might be created on other > processors. If a client makes an invocation using a partially obsolete > IOGR, it might fail to reach one or more of the replicas. If, however, > even one of the profiles addresses an object replica on a working > processor, the LOCATION_FORWARD_PERM exception can instruct the ORB at > the client to update the client's copy of the IOGR with a version that > includes profiles for the new replicas and excludes failed replicas. > Provided that the client makes invocations more frequently than > processors fail, the IOGR will continue to contain one or more profiles > that the client can use to access the object. Perhaps you can explain something else to me. Over time, as you say, the reference can become more and more stale -- and the FT spec is relying on LOCATION_FOWARD_PERM to update the reference. Ok, so I go and stick a reference in a database somewhere (like the naming service). The naming service has no way to determine whether the reference is stale or not. Furthermore the service will not find out about the reference being permanently location forwarded (since this isn't visible to the application). This means that eventually the reference will become useless. This is the one of the reasons why LOCATION_FORWARD_PERM was dumped from the spec. The FT group has claimed that this isn't a problem for fault tolerance -- but I think it actually is much MORE of a problem since the very archicture that FT is based on seems to require permanent churn and chaning of the reference. The reason why this isn't a problem for existing CORBA applications is because they are based on indirect binding -- that is the references generally point at an IMR and then are re-directed to the current location of the server. > [...] > Thanks. > > Louise 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: Fri, 3 Nov 2000 20:56:13 -0330 From: Matthew Newhook To: moser@ece.ucsb.edu Cc: jis@fpk.hp.com, ft-ftf@omg.org, orb_revision@omg.org, interop@omg.org, juergen@omg.org Subject: Re: Issue 3976 Message-ID: <20001103205613.D15957@ooc.com> References: <20001103172928.B14683@ooc.com> <200011032209.OAA13671@iota.ece.ucsb.edu> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <200011032209.OAA13671@iota.ece.ucsb.edu> Content-Type: text/plain; charset=us-ascii X-UIDL: i90e9nAn!!<56!!('Xd9 Hi, On Fri, Nov 03, 2000 at 02:09:49PM -0800, Louise Moser wrote: > [...] > Over a period of time, the processors that host the replicas of an > object might fail and new replacement replicas might be created on other > processors. If a client makes an invocation using a partially obsolete > IOGR, it might fail to reach one or more of the replicas. If, however, > even one of the profiles addresses an object replica on a working > processor, the LOCATION_FORWARD_PERM exception can instruct the ORB at > the client to update the client's copy of the IOGR with a version that > includes profiles for the new replicas and excludes failed replicas. > Provided that the client makes invocations more frequently than > processors fail, the IOGR will continue to contain one or more profiles > that the client can use to access the object. > > Constructing an IOGR whose profiles address the replicas of a group > reference manager or implementation repository does not change the > problem. The group reference manager must be a fault tolerant object, > addressed by an IOGR with multiple profiles. The replicas of the group > reference manager might fail and be replaced by new replicas on > different processors. Thus, IOGR for the group reference manager might > also need to be updated. > > If you really want a better grade of service based on pushing IOGR > updates to the clients, we could provide an IOGR Updating Service. Each > client would register each of its IOGRs with the IOGR Updating Service > and the service would notify the client of each change to such an IOGR > (of course, this means that the client cannot remain a pure client). > The LOCATION_FORWARD_PERM provides almost as good a service but with > much less intrusion into the client application. So what you are basically doing is usign LOCATION_FORWARD_PERM as a method the contents "refreshing" an object reference. How does the ORB know when to reply to a request with a LOCATION_FORWARD_PERM? From the context of a request the ORB has no idea about the reference that the caller is using. > Thanks. > > Louise 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: Mon, 6 Nov 2000 09:47:49 -0800 (PST) Message-Id: <200011061747.JAA04796@iota.ece.ucsb.edu> X-Authentication-Warning: iota.ece.ucsb.edu: moser set sender to moser@alpha.ece.ucsb.edu using -f From: Louise Moser To: matthew@ooc.com Cc: jis@fpk.hp.com, ft-ftf@omg.org, orb_revision@omg.org, interop@omg.org, juergen@omg.org In-reply-to: <20001103205613.D15957@ooc.com> (message from Matthew Newhook on Fri, 3 Nov 2000 20:56:13 -0330) Subject: Re: Issue 3976 Reply-to: moser@ece.ucsb.edu Content-Type: text X-UIDL: aUL!! How does the ORB know when to reply to a request with a LOCATION_FORWARD_PERM? The IOGR's TAG_FT_GROUP component contains a version field that is incremented as each new version of the IOGR is constructed by the Replication Manager. The Client ORB copies this version number into the FT_GROUP_VERSION service context that it includes in each request message. The Server ORB, or perhaps the fault tolerance infrastructure, compares the version number in the service contextof the request message with the version number in the TAG_FT_GROUP component of the current IOGR for the Server. Basically, If the version number in the request message is less than the version number in the Server's IOGR, the Server ORB returns a LOCATION_FORWARD_PERM. If the version number in the request message is greater than the version number in the Server's IOGR, the Server ORB can invoke the get_object_group_ref() method of the Replication Manager to obtain the current version of the IOGR. For the precise semantics, see Section 27.2.7.1 of the adopted Fault Tolerant CORBA specification. The operation of these mechanisms is intended to be invisible to the application programs. They should be reasonably effective for references that are used frequently. For references that are used infrequently, such as years between uses, the mechanisms may be ineffective. Similarly, if the application stores the IOGR in a database, writes it on a postcard, etc., these mechanisms can do nothing to maintain that IOGR up to date until the application actually uses the reference. Thanks. Louise Date: Tue, 7 Nov 2000 18:44:50 +0100 (MET) Message-Id: <200011071744.SAA22464@hess.dinsunnet> From: Julien Maisonneuve To: matthew@ooc.com CC: moser@ece.ucsb.edu, terutt@lucent.com, ft-ftf@omg.org, orb_revision@omg.org, interop@omg.org In-reply-to: <20001102193816.C31065@ooc.com> (message from Matthew Newhook on Thu, 2 Nov 2000 19:38:16 -0330) Subject: Re: Issue 3976 Content-Type: text X-UIDL: 7A:e9OZ#!!@(1!!FlHe9 Hi folks, Date: Thu, 2 Nov 2000 19:38:16 -0330 From: Matthew Newhook > >Does this solution address how the Client application is made aware that > >an old reference It has must be replaced? Sorry, that doesn't help. The client simply by using the object reference cannot know that the location of the object has changed (ie: it doesn't know about location forwards, and all that good stuff) (unless of course the client has turned off automatic rebinding). Louise's answer seemed rather appropriate as Tom asked wether we told the application a reference had gone stale, which it doesn't. FT CORBA per se doesn't guarantee that a CORBA reference never goes stale, but it still does it a lot better than regular CORBA. Additional mechanisms outside the spec scope can increase the chance that it will not go stale. Or am I missing the point again ? :-) Julien. Date: Tue, 7 Nov 2000 18:54:23 +0100 (MET) Message-Id: <200011071754.SAA22473@hess.dinsunnet> From: Julien Maisonneuve To: matthew@ooc.com CC: moser@alpha.ece.ucsb.edu, terutt@lucent.com, ft-ftf@omg.org, orb_revision@omg.org, interop@omg.org In-reply-to: <20001103004441.B5461@ooc.com> (message from Matthew Newhook on Fri, 3 Nov 2000 00:44:41 -0330) Subject: Re: Issue 3976 Content-Type: text X-UIDL: -$!!!j>_d9J@'e97=9!! Date: Fri, 3 Nov 2000 00:44:41 -0330 From: Matthew Newhook Why doesn't the original reference point to a group reference manager -- similar to an implementation repository? In this way LOCATION_FORWARD_PERM isn't necessary (assuming that the manager isn't moved, of course). However, I don't consider that to be a typical problem, and so therefore not a showstopper. After all even if the manager is moved what good is location forward perm? Something has to be present to forward the request... Because then we must guarantee that at least one of the location managers with which the reference was orginally created will be there forever, which is hard to accept as limitation for a long running large scale system. The Locate forward combined with the heartbeat mechanism allows to refresh the references from time to time. Right, the manager eliminates the risk -- and the CORBA spec doesn't need to be changed, nothing needs to be added. This is a well known problem, with a well established well implemented solution. ORBs have been doing this for years. No. ORBs have delivered non-fault-tolerant systems for years. I also don't think that the LOCATION_FORWARD_PERM is necessary either for the above reasons. The above problem can not be perfectly solved by *any* means, so this is a moot point. Oh yes, sorry for the delay. Best regards, Julien. -- Julien Maisonneuve, PhD IP Unit B1-346 Alcatel Research & Innovation Alcanet: 2111 1577 Route de Nozay Tel: +33 1 6963 1577 91461 Marcoussis cedex Fax: +33 1 6963 1169 FRANCE Julien.Maisonneuve@alcatel.fr Date: Thu, 16 Nov 2000 16:48:13 -0800 (PST) From: Anita Jindal Reply-To: Anita Jindal Subject: Re: Voting on Issues 3747, 3908, 3976 To: ft-ftf@omg.org, juergen@omg.org, moser@ece.ucsb.edu Cc: Anita.Jindal@eng.sun.com, peter.walker@eng.sun.com, Ken.Cavanaugh@eng.sun.com MIME-Version: 1.0 Content-MD5: EHweJXUAZJZ3AWSZtriSAg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: m<#"!_*F!!A,W!!`_Y!! Sun Votes as follows: 3747: Yes 3908: Yes 3976: No ; The resolution is incomplete due to following reasons: - The IOGR is referenced in the core spec, without it's definition being included in the core spec. With the change specified in the resolution, the core spec will not be self contained. - The Portable Interceptors (PI) spec had removed the "permanent" flag from ForwardRequest after the deprecation of LOCATION_FORWARD_PERM. Although the semantics for LOCATION_FORWARD_PERM is being defined in the core spec by this resolution, there is no API in PI ForwardRequest exception to indicate semantics of LOCATION_FORWARD_PERM. - Thanks Anita > X-Authentication-Warning: iota.ece.ucsb.edu: moser set sender to moser@alpha.ece.ucsb.edu using -f > To: ft-ftf@omg.org, juergen@omg.org > Subject: Voting on Issues 3747, 3908, 3976 > > > Hello Everyone, > > Thank you for the discussion on Issues 3747, 3908, 3976. Here are the > Proposed Resolutions for these issues on which we will now vote. The > voting on these issues will close on Friday, November 17. > > Thanks. > > Louise Moser > Chair FT-FTF > > ======================================================================= > > ISSUE 3747 YES NO ABSTAIN > > The adopted draft specification defines State as a sequence. > This presents a problem when coding get_state() and set_state() for an > application whose state contains an any, because of the marshalling > required and because not all ORBs support the Portable Interceptor with > the Codec interface. The Replication Manager itself contains any values > and is such an application. > > Proposed Resolution: > > Replace the definition of State in Section 27.5.4 on pages 27-84 and > 27-85 and in Appendix A Consolidated IDL on page 27-102 by > > typedef any State; > > > ======================================================================= > > ISSUE 3908 YES NO ABSTAIN > > 13.6.7 of the CORBA 2.3 specification states: "The context data for a > particular service will be encoded as specified for its service-specific > OMG IDL definition, and that encoded representation will be encapsulated > in the context_data member of IOP::ServiceContext. (See Section 15.3.3, > Encapsulation, on page 15-13)." The descriptions of service contexts in > the FT specification are missing an explicit statement of the encoding > of the service context data. > > Proposed Resolution: > > Replace the first sentence of Section 27.2.7.1 on page 27-22 by > the following two sentences: > > "The FTGroupVersionServiceContext struct contains the version of > the object group reference for the server object group, which > allows the server to determine whether the client is using an > obsolete object group reference. When encoded in a request or reply > message header, the context_data component of the ServiceContext > struct shall contain a CDR encapsulation of the > FTGroupVersionServiceContext struct, which is defined below." > > Replace the first sentence of Section 27.2.8.1 on page 27-24 by > the following two sentences: > > "The FTRequestServiceContext is used to ensure that a request is > not executed more than once under fault conditions. When encoded > in a request or reply message header, the context_data component of > the ServiceContext struct shall contain a CDR encapsulation of the > FTRequestServiceContext struct, which is defined below." > > > ======================================================================= > > ISSUE 3976 YES NO ABSTAIN > > Earlier this year, the Interop RTF deprecated the LOCATION_FORWARD_PERM > exception because it was poorly specified and made implementation of > hash() difficult. However, for Fault Tolerant CORBA, the > LOCATION_FORWARD_PERM exception is essential. > > Proposed Resolution: > > 1. Add to the end of the first paragraph of Section 4.3.6.1 > > "For interoperable object group references, the identifier shall be > the object group identifier which is not changed when the reference > is updated by the LOCATION_FORWARD_PERM exception." > > 2. Change the following resolution of Interop RTF, which was to be included > in Section 13.4.3.2 > > "Note: Usage of LOCATION_FORWARD_PERM is now deprecated, due to problems > it causes with the semantics of the Object::hash() operation. > LOCATION_FORWARD_PERM features could be removed from some future GIOP > versions if solutions to these problems are not provided." > > to read > > "Note: Usage of LOCATION_FORWARD_PERM to return an object reference that > is not an interoperable object group reference is now deprecated, due to > problems it causes with the semantics of the Object::hash() operation." > > 3. Change the following resolution of Interop RTF, which was to be > included in Section 13.4.6.1 > > "Note: Usage of LOCATION_FORWARD_PERM is now deprecated, due to problems > it causes with the semantics of the Object::hash() operation. > LOCATION_FORWARD_PERM features could be removed from some future GIOP > versions if solutions to these problems are not provided." > > to read > > "Note: Usage of LOCATION_FORWARD_PERM to return an object reference that > is not an interoperable object group reference is now deprecated, due to > problems it causes with the semantics of the Object::hash() operation." > > 4. Change the following resolution of Interop RTF, which was to be > included in Section 15.6 > > "Note: Usage of LOCATION_FORWARD_PERM and OBJECT_FORWARD_PERM is now > deprecated, due to problems it causes with the semantics of the > Object::hash() operation. LOCATION_FORWARD_PERM and OBJECT_FORWARD_PERM > features could be removed from some future GIOP versions if solutions to > these problems are not provided." > > to read > > "Note: Usage of LOCATION_FORWARD_PERM and OBJECT_FORWARD_PERM to return > an object reference that is not an interoperable object group reference > is now deprecated, due to problems it causes with the semantics of the > Object::hash() operation." > > 5. In Section 27.2.5, immediately before 27.2.5.1, insert the following > paragraph: > > "The first of these three options, access directly to a member of a > server object group, requires the use of the LOCATION_FORWARD_PERM > exception. As object replicas fail and are replaced by new > replicas, a stage may be reached at which all of the original > replicas, cited in the original interoperable object group > reference for the object, are inaccessible. Continued use of the > original reference will cause system failure. The > LOCATION_FORWARD_PERM exception allows such a reference to be > replaced by an updated reference that contains profiles for the new > replacement replicas. Thus, the LOCATION_FORWARD_PERM exception is > not deprecated when it is used to return an interoperable object > group reference. The use of the LOCATION_FORWARD_PERM exception to > return a reference that is not an interoperable object group > reference continues to be deprecated." > > 6. In Section 27.2.6, after the first paragraph on page 27-21, insert > the following paragraph: > > "The temporal scope of the replacement reference provided by > LOCATION_FORWARD_PERM is ORB lifetime or the next > LOCATION_FORWARD_PERM. It is safe, and appropriate, for an ORB to > replace any reference that contains the same fault tolerance domain > identifier, the same object group identifier and a smaller value of > the version of the object group reference." > > 7. In Section 27.2.3.6 on page 27-18, replace "Follows the semantics > above." by > > "Follows the semantics for is_equivalent(). An interoperable > object group reference contains an object group identifier that is > unique and immutable over the lifetime of the object group. For > such a reference, the value of hash() shall be derived from the > object group identifier. For references that are not interoperable > object group references, the value of hash() continues to be > derived as at present." >