Issue 3516: following question regarding modifications to CORBA core (ft-ftf) Source: Oracle (Dr. Anita Jindal, nobody) Nature: Clarification Severity: Summary: Basically, the Failure OBJ_ADAPTER is considered a failover condition in the document that was sent out. In most cases OBJ_ADAPTER exception may be thrown when there is an internal ORB error. In case of an internal ORB error, the retry on the TAG_ALTERNATE_IIOP_ADDRESS may still yield the same exception. This may be inefficient. Do you see situations where doing a failover on this particular exception is useful. Resolution: Remove OBJ_ADAPTER from this list. Revised Text: Actions taken: March 29, 2000: received issue May 24, 2001: closed issue Discussion: End of Annotations:===== Date: Wed, 29 Mar 2000 08:50:29 -0800 (PST) From: Anita Jindal Reply-To: Anita Jindal Subject: Re: Fault Tolerant CORBA - Draft Adopted Specification - .pdf file To: moser@chi.ece.ucsb.edu Cc: ft-ftf@omg.org, peter.walker@eng.sun.com, rip-dev@eng.sun.com MIME-Version: 1.0 Content-MD5: DFPHyCo10W4Dl5XYdsBVMQ== 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: Go0!!~@id94JY!!2$~e9 Louise, I have a following question regarding modifications to CORBA core. Basically, the Failure OBJ_ADAPTER is considered a failover condition in the document that was sent out. In most cases OBJ_ADAPTER exception may be thrown when there is an internal ORB error. In case of an internal ORB error, the retry on the TAG_ALTERNATE_IIOP_ADDRESS may still yield the same exception. This may be inefficient. Do you see situations where doing a failover on this particular exception is useful. - Thanks Anita > Mime-Version: 1.0 > To: ft-ftf@omg.org > Subject: Fault Tolerant CORBA - Draft Adopted Specification - .pdf > file > X-Sender: giddiv@postel X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Sep 2000 10:41:11 -0400 To: orb_revision@omg.org From: Victor Giddings Subject: comments solicited for Issue 3516 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: ^MD!!Yd~e980j!!MD!e9 The FT-FTF is interested in comments from this group on issue 3516 http://cgi.omg.org/issues/issue3516.txt assigned to the FT-FTF. This issue concerns the (small) part of the FT CORBA specification that modifies the core and has been reviewed and commented on by many of the members of this group. The current adopted specification lists the following exceptions as those for which transparent re-invocation is allowed (when accompanied by a COMPLETED_NO status): COMM_FAILURE TRANSIENT NO_RESPONSE OBJ_ADAPTER Issue 3516 questions the utility of OBJ_ADAPTER on this list. Victor Giddings victor.giddings@ois.com Senior Product Engineer +1 703 295 6500 Objective Interface Systems Fax: +1 703 296 6501 Date: Tue, 26 Sep 2000 11:34:39 -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: Victor Giddings Cc: orb_revision@omg.org Subject: Re: comments solicited for Issue 3516 References: <4.3.2.7.2.20000925163548.00df3b50@postel> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: XP:e9R\6!!^BGe9V#U!! Victor Giddings wrote: > > The FT-FTF is interested in comments from this group on issue 3516 http://cgi.omg.org/issues/issue3516.txt assigned to the FT-FTF. This issue concerns the (small) part of the FT CORBA specification that modifies the core and has been reviewed and commented on by many of the members of this group. > > The current adopted specification lists the following exceptions as those for which transparent re-invocation is allowed (when accompanied by a COMPLETED_NO status): > COMM_FAILURE > TRANSIENT > NO_RESPONSE > OBJ_ADAPTER > > Issue 3516 questions the utility of OBJ_ADAPTER on this list. > > Victor Giddings victor.giddings@ois.com > Senior Product Engineer +1 703 295 6500 > Objective Interface Systems Fax: +1 703 296 6501 I guess I am missing something. If one ORB barfs and sends back a OBJ_ADAPTER exception because the POA that was managing a particular invocation went South, why does that imply that another ORB that tries the same invocation is likely to get the same problem with the POA handling the invocation? Generally it seems that the OBJ_ADAPTER exception is raised, at least in the POA when something horribly wrong happens, like for some reason the servant disappears from the active map or such. Presumably such bad things do not happen synchronously in all ORBs managing all replica of the object, 'cause otherwise the whole FT by replication thing would not work too well. So what am I missing in the argument presented in the issue archive on issue 3516? Regards, Jishnu. From: "Robert E. Gruber" To: "Jishnu Mukerji (by way of Victor Giddings )" , Cc: "Robert E. Gruber" Subject: RE: comments solicited for Issue 3516 Date: Tue, 26 Sep 2000 12:57:13 -0400 Message-ID: <003101c027da$d10f79a0$c216cf87@pong.research.att.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <4.3.2.7.2.20000926122246.01bf0180@postel> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: g[ld9a/&"!:(by way of Victor Giddings ) Subject: Re: comments solicited for Issue 3516 Mime-Version: 1.0 Sender: victor.giddings@ois.com Content-Type: text/plain; charset="us-ascii" X-UIDL: a*=!!?W4!!Cg8!!K=%!! Victor Giddings wrote: > > The FT-FTF is interested in comments from this group on issue 3516 http://cgi.omg.org/issues/issue3516.txt assigned to the FT-FTF. This issue concerns the (small) part of the FT CORBA specification that modifies the core and has been reviewed and commented on by many of the members of this group. > > The current adopted specification lists the following exceptions as those for which transparent re-invocation is allowed (when accompanied by a COMPLETED_NO status): > COMM_FAILURE > TRANSIENT > NO_RESPONSE > OBJ_ADAPTER > > Issue 3516 questions the utility of OBJ_ADAPTER on this list. Like Jishnu, I am very suspicious of including OBJ_ADATPTER in this list. The "standard" minor codes assigned so far for OBJ_ADAPTER do not give the impression that the problem is likely to be corrected by a transparent rebind or re-invocation. In a recent meeting of the CORE RTF, it was generally agreed that the semantics of completion_status was too muddy and far too much code has been written to make it feasible to put the genie back in the bottle and define clearer semantics. Of course, if your issue is limited to the FT world, and isn't going to require changes by ORBs that don't claim to support FT, you have a lot more leeway in trying to pin down better semantics for completion_status. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Sender: giddiv@postel X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Sep 2000 14:14:51 -0400 To: orb_revision@omg.org From: Victor Giddings Subject: Re: comments solicited for Issue 3516 Cc: ft-ftf@omg.org In-Reply-To: <39D0DEAA.7A2B61C4@floorboard.com> References: <4.3.2.7.2.20000925163548.00df3b50@postel> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: $-Ae9jX0!!gkc!!H9#e9 At 10:36 AM 9/26/00 -0700, Jonathan Biggar wrote: >Victor Giddings wrote: >> >> The FT-FTF is interested in comments from this group on issue 3516 http://cgi.omg.org/issues/issue3516.txt assigned to the FT-FTF. This issue concerns the (small) part of the FT CORBA specification that modifies the core and has been reviewed and commented on by many of the members of this group. >> >> The current adopted specification lists the following exceptions as those for which transparent re-invocation is allowed (when accompanied by a COMPLETED_NO status): >> COMM_FAILURE >> TRANSIENT >> NO_RESPONSE >> OBJ_ADAPTER >> >> Issue 3516 questions the utility of OBJ_ADAPTER on this list. > >Like Jishnu, I am very suspicious of including OBJ_ADATPTER in this >list. The "standard" minor codes assigned so far for OBJ_ADAPTER do not >give the impression that the problem is likely to be corrected by a >transparent rebind or re-invocation. Yes, but this leaves open those who use this exception for other unspecified reasons. This sentiment seemed to be the concensus of the FTFTF, but we also realized that someone put this exception on the list in the first place. So we would like to understand why if possible. >In a recent meeting of the CORE RTF, it was generally agreed that the >semantics of completion_status was too muddy and far too much code >has >been written to make it feasible to put the genie back in the bottle >and >define clearer semantics. > >Of course, if your issue is limited to the FT world, and isn't going >to >require changes by ORBs that don't claim to support FT, you have a >lot >more leeway in trying to pin down better semantics for >completion_status. No, the FT CORBA spec added this requirement for transparent rebind to the core CORBA specification: "Each time a client ORB attempts to invoke a method, it must not abandon the invocation and raise an exception to the client application until it has tried to invoke the server using all of the alternative IIOP addresses in the IOR, or has received a "non-failover" condition. Alternative addresses include all of the host/port pairs from all of the TAG_INTERNET_IOP profiles in the IOR, and all of the TAG_ALTERNATE_IIOP_ADDRESS components." >-- >Jon Biggar >Floorboard Software >jon@floorboard.com >jon@biggar.org Also, I forgot to request that these discussions be cross-posted to ft-ftf@omg.org. I have forwarded everything so far, but please cc ft-ftf from now on. Victor Giddings victor.giddings@ois.com Senior Product Engineer +1 703 295 6500 Objective Interface Systems Fax: +1 703 296 6501