Issue 11403: Section: 13.6 Server mapping (cxx_revision) Source: (, ) Nature: Enhancement Severity: Significant Summary: Althrough I report my issue as a C++ issue, actually it is a common issue for other languages also. In current CORBA standard, a activated CORBA Servant object in the POA is shared by all the clients. But in many applications, a client connects to the server and calls some CORBA object methods to create a lot of connection related CORBA objects. Normally, the client will call "destroy" method of these CORBA object to destroy them before existing. But if the client exists abnormally, these created CORBA object will never be destroyed and never be used by any client. We can call this kind of CORBA object as "floating" CORBA object. The CORBA server application runs longer, the "floating" CORBA objects becomes more. And eventually, these "floating" CORBA objects will consume all the memory resources/CPU resources, then the CORBA server crashes and has to be restarted. The "floating" CORBA objects problem at the server side is not easy to be solved. For this problem, if the CORBA standard provides a method to solve it, the CORBA server will run more robust. Actually, the underlying network connection broken can be detected very effectively and rapidly. The CORBA server just simply ignores the network connection lost event and does not pass it to activated CORBA object even if the CORBA object is connection related object because current CORBA standard thinks that all the CORBA objects in the server are shared to all clients. If the server can notify the network connection lost event to the connection related CORBA objects, the developper can do the clean job on it. A simple method can solve the "floating" CORBA object problem. It is not required to add any new interface or data structure to current orb.idl. It is just required to add some new language mapping methods at server side only. I will give an example in C++ to show this simple method. A IShared,IConnSpec and IOtherConnectionSpec interfaces are defined below: interface IOtherConnectionSpec { ... } interface IConnectionSpec { IOtherConnectionSpec someMethod(); } interface IShared { IConnectionSpec createConnSpec( in string param ); }; These interfaces will be used in this example. 1) the IShared will be shared by all the clients, it is activated like this: SharedImpl sharedImpl( ... ); ... sharedImpl._this(); 2) add new mapping method for the "POA_IShared::createConnSpec()" like this: IConnectionSpec_ptr POA_IShared::createConnSpec( char* param, const ConnectionContext& connCtx ); In this method, a parameter named ConnectionContext that represents the connection between the client and server is added. This method has a default implementation like this: IConnectionSpec_ptr POA_IShared::createConnSpec( const char* param, const ConnectionContext& connCtx ){ //just ignore the connCtx like the current CORBA standard defines return createConnSpec( param ); } 3) If the user wants to create a connection related object, he/she must overload the "IConnectionSpec_ptr createConnSpec( char* param, const ConnectionContext& connCtx )" method and active the object with "this_( const ConnectionContext& connCtx )" method: IConnectionSpec_ptr POA_IShared::createConnSpec( const char* param, const ConnectionContext& connCtx ){ ... IConnectionSpec *connSpecImpl = new IConnectionSpec( ... ); ... //use the connection related active method return connSpecImpl->this_( connCtx ); } in this method, the user uses the "this_( const ConnectionContext& connCtx)" method instead of the old "this()"" method to active the CORBA object. This activated CORBA object becomes a connection related object instead of shared object. Note: User can use the "this_( const ConnectionContext& connCtx)" method to active a shared object also. At this time, the ConnectionContext is a global variable "NO_CONNECTION_CONTEXT". 4) add a new mapping method named "getConnectionContext()" for every CORBA object. const ConnectionContext& IShared::getConnectionContext(); const ConnectionContext& POA_IConnectionSpec::getConnectionContext(); In this way, the IConnectionSpec can create and activate any other connection related CORBA object like this: IOtherConnectionSpec_ptr POA_IConnectionSpec::someMethod() { ... OtherConnectionSpecImpl *otherConnSpecImpl = new OtherConnectionSpecImpl(...); ... return otherConnSpecImpl->this_( getConnectionContext() ); //or ? //return otherConnSpecImpl->this_( this ); } 5) add a new mapping method named "connectionLost()" for every CORBA object. When the network connection is lost, the CORBA server should find all the CORBA object associated with this network connection and call their "connectionLost()" method. The "connectionLost()" and its default implementation is listed below: void POA_IConnectionSpec::connectionLost() { //just delete this connection related object simply delete this; } void POA_IOtherConnectionSpec::connectionLost() { //just delete this connection related object simply delete this; } Because the SharedImpl object that created in the 1) step does not assicate with any connection, its "connectionLost()" method will not be called for ever. Resolution: Revised Text: Actions taken: September 14, 2007: received issue Discussion: deferred in June 2011 to the next RTF End of Annotations:===== m: webmaster@omg.org Date: 14 Sep 2007 08:18:16 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Ou changhua Company: Alcatel-Lucent mailFrom: changhua.ou@alcatel-lucent.com Notification: Yes Specification: C++ Language Mapping Specification Section: 13.6 Server mapping FormalNumber: 03-06-03 Version: 1.1 RevisionDate: June 2003 Page: 1-129 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Description Althrough I report my issue as a C++ issue, actually it is a common issue for other languages also. In current CORBA standard, a activated CORBA Servant object in the POA is shared by all the clients. But in many applications, a client connects to the server and calls some CORBA object methods to create a lot of connection related CORBA objects. Normally, the client will call "destroy" method of these CORBA object to destroy them before existing. But if the client exists abnormally, these created CORBA object will never be destroyed and never be used by any client. We can call this kind of CORBA object as "floating" CORBA object. The CORBA server application runs longer, the "floating" CORBA objects becomes more. And eventually, these "floating" CORBA objects will consume all the memory resources/CPU resources, then the CORBA server crashes and has to be restarted. The "floating" CORBA objects problem at the server side is not easy to be solved. For this problem, if the CORBA standard provides a method to solve it, the CORBA server will run more robust. Actually, the underlying network connection broken can be detected very effectively and rapidly. The CORBA server just simply ignores the network connection lost event and does not pass it to activated CORBA object even if the CORBA object is connection related object because current CORBA standard thinks that all the CORBA objects in the server are shared to all clients. If the server can notify the network connection lost event to the connection related CORBA objects, the developper can do the clean job on it. A simple method can solve the "floating" CORBA object problem. It is not required to add any new interface or data structure to current orb.idl. It is just required to add some new language mapping methods at server side only. I will give an example in C++ to show this simple method. A IShared,IConnSpec and IOtherConnectionSpec interfaces are defined below: interface IOtherConnectionSpec { ... } interface IConnectionSpec { IOtherConnectionSpec someMethod(); } interface IShared { IConnectionSpec createConnSpec( in string param ); }; These interfaces will be used in this example. 1) the IShared will be shared by all the clients, it is activated like this: SharedImpl sharedImpl( ... ); ... sharedImpl._this(); 2) add new mapping method for the "POA_IShared::createConnSpec()" like this: IConnectionSpec_ptr POA_IShared::createConnSpec( char* param, const ConnectionContext& connCtx ); In this method, a parameter named ConnectionContext that represents the connection between the client and server is added. This method has a default implementation like this: IConnectionSpec_ptr POA_IShared::createConnSpec( const char* param, const ConnectionContext& connCtx ){ //just ignore the connCtx like the current CORBA standard defines return createConnSpec( param ); } 3) If the user wants to create a connection related object, he/she must overload the "IConnectionSpec_ptr createConnSpec( char* param, const ConnectionContext& connCtx )" method and active the object with "this_( const ConnectionContext& connCtx )" method: IConnectionSpec_ptr POA_IShared::createConnSpec( const char* param, const ConnectionContext& connCtx ){ ... IConnectionSpec *connSpecImpl = new IConnectionSpec( ... ); ... //use the connection related active method return connSpecImpl->this_( connCtx ); } in this method, the user uses the "this_( const ConnectionContext& connCtx)" method instead of the old "this()"" method to active the CORBA object. This activated CORBA object becomes a connection related object instead of shared object. Note: User can use the "this_( const ConnectionContext& connCtx)" method to active a shared object also. At this time, the ConnectionContext is a global variable "NO_CONNECTION_CONTEXT". 4) add a new mapping method named "getConnectionContext()" for every CORBA object. const ConnectionContext& IShared::getConnectionContext(); const ConnectionContext& POA_IConnectionSpec::getConnectionContext(); In this way, the IConnectionSpec can create and activate any other connection related CORBA object like this: IOtherConnectionSpec_ptr POA_IConnectionSpec::someMethod() { ... OtherConnectionSpecImpl *otherConnSpecImpl = new OtherConnectionSpecImpl(...); ... return otherConnSpecImpl->this_( getConnectionContext() ); //or ? //return otherConnSpecImpl->this_( this ); } 5) add a new mapping method named "connectionLost()" for every CORBA object. When the network connection is lost, the CORBA server should find all the CORBA object associated with this network connection and call their "connectionLost()" method. The "connectionLost()" and its default implementation is listed below: void POA_IConnectionSpec::connectionLost() { //just delete this connection related object simply delete this; } void POA_IOtherConnectionSpec::connectionLost() { //just delete this connection related object simply delete this; } Because the SharedImpl object that created in the 1) step does not assicate with any connection, its "connectionLost()" method will not be called for ever. From: "Johnny Willemsen" To: "'Juergen Boldt'" , , , , Subject: RE: issue 11403 -- Language Mapping issue Date: Tue, 25 Sep 2007 11:22:32 +0200 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acf24qS58r2RPCDdRzyvT1wk80h64gIctvBw X-Virus-Scanned: by XS4ALL Virus Scanner X-Spam-Status: No, hits=0.4 required=5.0 tests=HTML_10_20,HTML_FONT_COLOR_BLUE,HTML_MESSAGE,IN_REP_TO, MISSING_OUTLOOK_NAME,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Hi, This doesn't look to me something for the C++ RTF, more for the general CORBA RTF, but personally I think this is more an application issue, not a CORBA issue. Johnny -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, September 14, 2007 5:11 PM To: issues@omg.org; cxx_revision@omg.org; corba-rtf@omg.org; corba-e-ftf@omg.org Subject: issue 11403 -- Language Mapping issue I registered this issue under the C++ RTF From: webmaster@omg.org Date: 14 Sep 2007 08:18:16 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Ou changhua Company: Alcatel-Lucent mailFrom: changhua.ou@alcatel-lucent.com Notification: Yes Specification: C++ Language Mapping Specification Section: 13.6 Server mapping FormalNumber: 03-06-03 Version: 1.1 RevisionDate: June 2003 Page: 1-129 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Description Althrough I report my issue as a C++ issue, actually it is a common issue for other languages also. In current CORBA standard, a activated CORBA Servant object in the POA is shared by all the clients. But in many applications, a client connects to the server and calls some CORBA object methods to create a lot of connection related CORBA objects. Normally, the client will call "destroy" method of these CORBA object to destroy them before existing. But if the client exists abnormally, these created CORBA object will never be destroyed and never be used by any client. We can call this kind of CORBA object as "floating" CORBA object. The CORBA server application runs longer, the "floating" CORBA objects becomes more. And eventually, these "floating" CORBA objects will consume all the memory resources/CPU resources, then the CORBA server crashes and has to be restarted. The "floating" CORBA objects problem at the server side is not easy to be solved. For this problem, if the CORBA standard provides a method to solve it, the CORBA server will run more robust. Actually, the underlying network connection broken can be detected very effectively and rapidly. The CORBA server just simply ignores the network connection lost event and does not pass it to activated CORBA object even if the CORBA object is connection related object because current CORBA standard thinks that all the CORBA objects in the server are shared to all clients. If the server can notify the network connection lost event to the connection related CORBA objects, the developper can do the clean job on it. A simple method can solve the "floating" CORBA object problem. It is not required to add any new interface or data structure to current orb.idl. It is just required to add some new language mapping methods at server side only. I will give an example in C++ to show this simple method. A IShared,IConnSpec and IOtherConnectionSpec i .reve rof dellac eb ton lliw dohtem ")(tsoLnoitcennoc" sti ,noitcennoc yna htiw etacissa ton seod pets )1 eht ni detaerc taht tcejbo lpmIderahS eht esuaceB } ;siht eteled ylpmis tcejbo detaler noitcennoc siht eteled tsuj// { )(tsoLnoitcennoc::cepSnoitcennoCrehtOI_AOP diov } ;siht eteled ylpmis tcejbo detaler noitcennoc siht eteled tsuj// { )(tsoLnoitcennoc::cepSnoitcennoCI_AOP diov :woleb detsil si noitatnemelpmi tluafed sti dna ")(tsoLnoitcennoc" ehT .dohtem ")(tsoLnoitcennoc" rieht llac dna noitcennoc krowten siht htiw detaicossa tcejbo ABROC eht lla dnif dluohs revres ABROC eht ,tsol si noitcennoc krowten eht nehW .tcejbo ABROC yreve rof ")(tsoLnoitcennoc" deman dohtem gnippam wen a dda )5 } ;) siht (_siht>-lpmIcepSnnoCrehto nruter// ? ro// ;) )(txetnoCnoitcennoCteg (_siht>-lpmIcepSnnoCrehto nruter ... ;)...(lpmIcepSnoitcennoCrehtO wen = lpmIcepSnnoCrehto* lpmIcepSnoitcennoCrehtO ... { )(dohteMemos::cepSnoitcennoCI_AOP rtp_cepSnoitcennoCrehtOI :siht ekil tcejbo ABROC detaler noitcennoc rehto yna etavitca dna etaerc nac cepSnoitcennoCI eht ,yaw siht nI ;)(txetnoCnoitcennoCteg::cepSnoitcennoCI_AOP &txetnoCnoitcennoC tsnoc ;)(txetnoCnoitcennoCteg::derahSI &txetnoCnoitcennoC tsnoc .tcejbo ABROC yreve rof ")(txetnoCnoitcennoCteg" deman dohtem gnippam wen a dda )4 ."TXETNOC_NOITCENNOC_ON" elbairav labolg a si txetnoCnoitcennoC eht ,emit siht tA .osla tcejbo derahs a evitca ot dohtem ")xtCnnoc &txetnoCnoitcennoC tsnoc (_siht" eht esu nac resU :etoN .tcejbo derahs fo daetsni tcejbo detaler noitcennoc a semoceb tcejbo ABROC detavitca sihT .tcejbo ABROC eht evitca ot dohtem "")(siht" dlo eht fo daetsni dohtem ")xtCnnoc &txetnoCnoitcennoC tsnoc (_siht" eht sesu resu eht ,dohtem siht ni } ;) xtCnnoc (_siht>-lpmIcepSnnoc nruter dohtem evitca detaler noitcennoc eht esu// ... ;) ... (cepSnoitcennoCI wen = lpmIcepSnnoc* cepSnoitcennoCI ... {) xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc tsnoc (cepSnnoCetaerc::derahSI_AOP rtp_cepSnoitcennoCI :dohtem ") xtCnnoc &txetnoCnoitcennoC tsnoc (_siht" htiw tcejbo eht evitca dna dohtem ") xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc (cepSnnoCetaerc rtp_cepSnoitcennoCI" eht daolrevo tsum ehs/eh ,tcejbo detaler noitcennoc a etaerc ot stnaw resu eht fI )3 } ;) marap (cepSnnoCetaerc nruter senifed dradnats ABROC tnerruc eht ekil xtCnnoc eht erongi tsuj// {) xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc tsnoc (cepSnnoCetaerc::derahSI_AOP rtp_cepSnoitcennoCI :siht ekil noitatnemelpmi tluafed a sah dohtem sihT .dedda si revres dna tneilc eht neewteb noitcennoc eht stneserper taht txetnoCnoitcennoC deman retemarap a ,dohtem siht nI ;) xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc (cepSnnoCetaerc::derahSI_AOP rtp_cepSnoitcennoCI :siht ekil ")(cepSnnoCetaerc::derahSI_AOP" eht rof dohtem gnippam wen dda )2 ;)(siht_.lpmIderahs ... ;) ... (lpmIderahs lpmIderahS :siht ekil detavitca si ti ,stneilc eht lla yb derahs eb lliw derahSI eht )1 .elpmaxe siht ni desu eb lliw secafretni esehT ;} ;) marap gnirts ni (cepSnnoCetaerc cepSnoitcennoCI { derahSI ecafretni } ;)(dohteMemos cepSnoitcennoCrehtOI { cepSnoitcennoCI ecafretni } ... { cepSnoitcennoCrehtOI ecafretni :woleb denifed era secafretn Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Cc: "'Juergen Boldt'" , , , , From: Bill Beckwith Subject: Re: issue 11403 -- Language Mapping issue Date: Tue, 25 Sep 2007 11:17:53 -0400 To: "Johnny Willemsen" X-Mailer: Apple Mail (2.752.3) Hi Johnny, This is looks to me like a shortcoming of the implementation of the ORB. Robust shutdown of the ORB is possible with the existing specification. By "robust" I mean that the ORB shutdown process is safe in the presence of multiple threads, does not leave behind pointers to deleted memory, resources are completely reclaimed, et al. Given the ORB doesn't have the robust shutdown semantics then I could see how an application might be structured to release resources in an order required by that ORB. Bill On Sep 25, 2007, at 5:22 AM, Johnny Willemsen wrote: Hi, This doesn't look to me something for the C++ RTF, more for the general CORBA RTF, but personally I think this is more an application issue, not a CORBA issue. Johnny -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, September 14, 2007 5:11 PM To: issues@omg.org; cxx_revision@omg.org; corba-rtf@omg.org; corba-e-ftf@omg.org Subject: issue 11403 -- Language Mapping issue I registered this issue under the C++ RTF From: webmaster@omg.org Date: 14 Sep 2007 08:18:16 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Ou changhua Company: Alcatel-Lucent mailFrom: changhua.ou@alcatel-lucent.com Notification: Yes Specification: C++ Language Mapping Specification Section: 13.6 Server mapping FormalNumber: 03-06-03 Version: 1.1 RevisionDate: June 2003 Page: 1-129 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Description Althrough I report my issue as a C++ issue, actually it is a common issue for other languages also. In current CORBA standard, a activated CORBA Servant object in the POA is shared by all the clients. But in many applications, a client connects to the server and calls some CORBA object methods to create a lot of connection related CORBA objects. Normally, the client will call "destroy" method of these CORBA object to destroy them before existing. But if the client exists abnormally, these created CORBA object will never be destroyed and never be used by any client. We can call this kind of CORBA object as "floating" CORBA object. The CORBA server application runs longer, the "floating" CORBA objects becomes more. And eventually, these "floating" CORBA objects will consume all the memory resources/CPU resources, then the CORBA server crashes and has to be restarted. The "floating" CORBA objects problem at the server side is not easy to be solved. For this problem, if the CORBA standard provides a method to solve it, the CORBA server will run more robust. Actually, the underlying network connection broken can be detected very effectively and rapidly. The CORBA server just simply ignores the network connection lost event and does not pass it to activated CORBA object even if the CORBA object is connection related object because current CORBA standard thinks that all the CORBA objects in the server are shared to all clients. If the server can notify the network connection lost event to the connection related CORBA objects, the developper can do the clean job on it. A simple method can solve the "floating" CORBA object problem. It is not required to add any new interface or data structure to current orb.idl. It is just required to add some new language mapping methods at server side only. I will give an example in C++ to show this simple method. A IShared,IConnSpec and IOtherConnectionSpec i .reve rof dellac eb ton lliw dohtem ")(tsoLnoitcennoc" sti ,noitcennoc yna htiw etacissa ton seod pets )1 eht ni detaerc taht tcejbo lpmIderahS eht esuaceB } ;siht eteled ylpmis tcejbo detaler noitcennoc siht eteled tsuj// { )(tsoLnoitcennoc::cepSnoitcennoCrehtOI_AOP diov } ;siht eteled ylpmis tcejbo detaler noitcennoc siht eteled tsuj// { )(tsoLnoitcennoc::cepSnoitcennoCI_AOP diov :woleb detsil si noitatnemelpmi tluafed sti dna ")(tsoLnoitcennoc" ehT .dohtem ")(tsoLnoitcennoc" rieht llac dna noitcennoc krowten siht htiw detaicossa tcejbo ABROC eht lla dnif dluohs revres ABROC eht ,tsol si noitcennoc krowten eht nehW .tcejbo ABROC yreve rof ")(tsoLnoitcennoc" deman dohtem gnippam wen a dda )5 } ;) siht (_siht>-lpmIcepSnnoCrehto nruter// ? ro// ;) )(txetnoCnoitcennoCteg (_siht>-lpmIcepSnnoCrehto nruter ... ;)...(lpmIcepSnoitcennoCrehtO wen = lpmIcepSnnoCrehto* lpmIcepSnoitcennoCrehtO ... { )(dohteMemos::cepSnoitcennoCI_AOP rtp_cepSnoitcennoCrehtOI :siht ekil tcejbo ABROC detaler noitcennoc rehto yna etavitca dna etaerc nac cepSnoitcennoCI eht ,yaw siht nI ;)(txetnoCnoitcennoCteg::cepSnoitcennoCI_AOP &txetnoCnoitcennoC tsnoc ;)(txetnoCnoitcennoCteg::derahSI &txetnoCnoitcennoC tsnoc .tcejbo ABROC yreve rof ")(txetnoCnoitcennoCteg" deman dohtem gnippam wen a dda )4 ."TXETNOC_NOITCENNOC_ON" elbairav labolg a si txetnoCnoitcennoC eht ,emit siht tA .osla tcejbo derahs a evitca ot dohtem ")xtCnnoc &txetnoCnoitcennoC tsnoc (_siht" eht esu nac resU :etoN .tcejbo derahs fo daetsni tcejbo detaler noitcennoc a semoceb tcejbo ABROC detavitca sihT .tcejbo ABROC eht evitca ot dohtem "")(siht" dlo eht fo daetsni dohtem ")xtCnnoc &txetnoCnoitcennoC tsnoc (_siht" eht sesu resu eht ,dohtem siht ni } ;) xtCnnoc (_siht>-lpmIcepSnnoc nruter dohtem evitca detaler noitcennoc eht esu// ... ;) ... (cepSnoitcennoCI wen = lpmIcepSnnoc* cepSnoitcennoCI ... {) xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc tsnoc (cepSnnoCetaerc::derahSI_AOP rtp_cepSnoitcennoCI :dohtem ") xtCnnoc &txetnoCnoitcennoC tsnoc (_siht" htiw tcejbo eht evitca dna dohtem ") xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc (cepSnnoCetaerc rtp_cepSnoitcennoCI" eht daolrevo tsum ehs/eh ,tcejbo detaler noitcennoc a etaerc ot stnaw resu eht fI )3 } ;) marap (cepSnnoCetaerc nruter senifed dradnats ABROC tnerruc eht ekil xtCnnoc eht erongi tsuj// {) xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc tsnoc (cepSnnoCetaerc::derahSI_AOP rtp_cepSnoitcennoCI :siht ekil noitatnemelpmi tluafed a sah dohtem sihT .dedda si revres dna tneilc eht neewteb noitcennoc eht stneserper taht txetnoCnoitcennoC deman retemarap a ,dohtem siht nI ;) xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc (cepSnnoCetaerc::derahSI_AOP rtp_cepSnoitcennoCI :siht ekil ")(cepSnnoCetaerc::derahSI_AOP" eht rof dohtem gnippam wen dda )2 ;)(siht_.lpmIderahs ... ;) ... (lpmIderahs lpmIderahS :siht ekil detavitca si ti ,stneilc eht lla yb derahs eb lliw derahSI eht )1 .elpmaxe siht ni desu eb lliw secafretni esehT ;} ;) marap gnirts ni (cepSnnoCetaerc cepSnoitcennoCI { derahSI ecafretni } ;)(dohteMemos cepSnoitcennoCrehtOI { cepSnoitcennoCI ecafretni } ... { cepSnoitcennoCrehtOI ecafretni :woleb denifed era secafretn Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: "Johnny Willemsen" To: "'Bill Beckwith'" Cc: "'Juergen Boldt'" , , , , Subject: RE: issue 11403 -- Language Mapping issue Date: Tue, 25 Sep 2007 20:17:09 +0200 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acf/mNEBZ+dCqxLvSHKS3eblehnCvgABzhpQ X-Virus-Scanned: by XS4ALL Virus Scanner X-Spam-Status: No, hits=-0.5 required=5.0 tests=EMAIL_ATTRIBUTION,HTML_10_20,HTML_FONT_COLOR_BLUE, HTML_MESSAGE,IN_REP_TO,MAILTO_LINK,MISSING_OUTLOOK_NAME, REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Hi Bill, So far as I read this, the reporter asks for a why he can have CORBA objects that are specific to one client connection and when the client goes away abnormally the ORB will destroy the specific objects. I don't read a relationship with ORB shutdown, only with a shutdown of the client. The reporter assumes the ORB can easily detect that the client is dead, he ignores the fact that the underlying transport maybe hasn't that capability and the fact that the ORB can close connections if it likes. Johnny -------------------------------------------------------------------------------- From: Bill Beckwith [mailto:bill.beckwith@ois.com] Sent: Tuesday, September 25, 2007 5:18 PM To: Johnny Willemsen Cc: 'Juergen Boldt'; issues@omg.org; cxx_revision@omg.org; corba-rtf@omg.org; corba-e-ftf@omg.org Subject: Re: issue 11403 -- Language Mapping issue Hi Johnny, This is looks to me like a shortcoming of the implementation of the ORB. Robust shutdown of the ORB is possible with the existing specification. By "robust" I mean that the ORB shutdown process is safe in the presence of multiple threads, does not leave behind pointers to deleted memory, resources are completely reclaimed, et al. Given the ORB doesn't have the robust shutdown semantics then I could see how an application might be structured to release resources in an order required by that ORB. Bill On Sep 25, 2007, at 5:22 AM, Johnny Willemsen wrote: Hi, This doesn't look to me something for the C++ RTF, more for the general CORBA RTF, but personally I think this is more an application issue, not a CORBA issue. Johnny -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, September 14, 2007 5:11 PM To: issues@omg.org; cxx_revision@omg.org; corba-rtf@omg.org; corba-e-ftf@omg.org Subject: issue 11403 -- Language Mapping issue I registered this issue under the C++ RTF From: webmaster@omg.org Date: 14 Sep 2007 08:18:16 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Ou changhua Company: Alcatel-Lucent mailFrom: changhua.ou@alcatel-lucent.com Notification: Yes Specification: C++ Language Mapping Specification Section: 13.6 Server mapping FormalNumber: 03-06-03 Version: 1.1 RevisionDate: June 2003 Page: 1-129 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Description Althrough I report my issue as a C++ issue, actually it is a common issue for other languages also. In current CORBA standard, a activated CORBA Servant object in the POA is shared by all the clients. But in many applications, a client connects to the server and calls some CORBA object methods to create a lot of connection related CORBA objects. Normally, the client will call "destroy" method of these CORBA object to destroy them before existing. But if the client exists abnormally, these created CORBA object will never be destroyed and never be used by any client. We can call this kind of CORBA object as "floating" CORBA object. The CORBA server application runs longer, the "floating" CORBA objects becomes more. And eventually, these "floating" CORBA objects will consume all the memory resources/CPU resources, then the CORBA server crashes and has to be restarted. The "floating" CORBA objects problem at the server side is not easy to be solved. For this problem, if the CORBA standard provides a method to solve it, the CORBA server will run more robust. Actually, the underlying network connection broken can be detected very effectively and rapidly. The CORBA server just simply ignores the network connection lost event and does not pass it to activated CORBA object even if the CORBA object is connection related object because current CORBA standard thinks that all the CORBA objects in the server are shared to all clients. If the server can notify the network connection lost event to the connection related CORBA objects, the developper can do the clean job on it. A simple method can solve the "floating" CORBA object problem. It is not required to add any new interface or data structure to current orb.idl. It is just required to add some new language mapping methods at server side only. I will give an example in C++ to show this simple method. A IShared,IConnSpec and IOtherConnectionSpec i .reve rof dellac eb ton lliw dohtem ")(tsoLnoitcennoc" sti ,noitcennoc yna htiw etacissa ton seod pets )1 eht ni detaerc taht tcejbo lpmIderahS eht esuaceB } ;siht eteled ylpmis tcejbo detaler noitcennoc siht eteled tsuj// { )(tsoLnoitcennoc::cepSnoitcennoCrehtOI_AOP diov } ;siht eteled ylpmis tcejbo detaler noitcennoc siht eteled tsuj// { )(tsoLnoitcennoc::cepSnoitcennoCI_AOP diov :woleb detsil si noitatnemelpmi tluafed sti dna ")(tsoLnoitcennoc" ehT .dohtem ")(tsoLnoitcennoc" rieht llac dna noitcennoc krowten siht htiw detaicossa tcejbo ABROC eht lla dnif dluohs revres ABROC eht ,tsol si noitcennoc krowten eht nehW .tcejbo ABROC yreve rof ")(tsoLnoitcennoc" deman dohtem gnippam wen a dda )5 } ;) siht (_siht>-lpmIcepSnnoCrehto nruter// ? ro// ;) )(txetnoCnoitcennoCteg (_siht>-lpmIcepSnnoCrehto nruter ... ;)...(lpmIcepSnoitcennoCrehtO wen = lpmIcepSnnoCrehto* lpmIcepSnoitcennoCrehtO ... { )(dohteMemos::cepSnoitcennoCI_AOP rtp_cepSnoitcennoCrehtOI :siht ekil tcejbo ABROC detaler noitcennoc rehto yna etavitca dna etaerc nac cepSnoitcennoCI eht ,yaw siht nI ;)(txetnoCnoitcennoCteg::cepSnoitcennoCI_AOP &txetnoCnoitcennoC tsnoc ;)(txetnoCnoitcennoCteg::derahSI &txetnoCnoitcennoC tsnoc .tcejbo ABROC yreve rof ")(txetnoCnoitcennoCteg" deman dohtem gnippam wen a dda )4 ."TXETNOC_NOITCENNOC_ON" elbairav labolg a si txetnoCnoitcennoC eht ,emit siht tA .osla tcejbo derahs a evitca ot dohtem ")xtCnnoc &txetnoCnoitcennoC tsnoc (_siht" eht esu nac resU :etoN .tcejbo derahs fo daetsni tcejbo detaler noitcennoc a semoceb tcejbo ABROC detavitca sihT .tcejbo ABROC eht evitca ot dohtem "")(siht" dlo eht fo daetsni dohtem ")xtCnnoc &txetnoCnoitcennoC tsnoc (_siht" eht sesu resu eht ,dohtem siht ni } ;) xtCnnoc (_siht>-lpmIcepSnnoc nruter dohtem evitca detaler noitcennoc eht esu// ... ;) ... (cepSnoitcennoCI wen = lpmIcepSnnoc* cepSnoitcennoCI ... {) xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc tsnoc (cepSnnoCetaerc::derahSI_AOP rtp_cepSnoitcennoCI :dohtem ") xtCnnoc &txetnoCnoitcennoC tsnoc (_siht" htiw tcejbo eht evitca dna dohtem ") xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc (cepSnnoCetaerc rtp_cepSnoitcennoCI" eht daolrevo tsum ehs/eh ,tcejbo detaler noitcennoc a etaerc ot stnaw resu eht fI )3 } ;) marap (cepSnnoCetaerc nruter senifed dradnats ABROC tnerruc eht ekil xtCnnoc eht erongi tsuj// {) xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc tsnoc (cepSnnoCetaerc::derahSI_AOP rtp_cepSnoitcennoCI :siht ekil noitatnemelpmi tluafed a sah dohtem sihT .dedda si revres dna tneilc eht neewteb noitcennoc eht stneserper taht txetnoCnoitcennoC deman retemarap a ,dohtem siht nI ;) xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc (cepSnnoCetaerc::derahSI_AOP rtp_cepSnoitcennoCI :siht ekil ")(cepSnnoCetaerc::derahSI_AOP" eht rof dohtem gnippam wen dda )2 ;)(siht_.lpmIderahs ... ;) ... (lpmIderahs lpmIderahS :siht ekil detavitca si ti ,stneilc eht lla yb derahs eb lliw derahSI eht )1 .elpmaxe siht ni desu eb lliw secafretni esehT ;} ;) marap gnirts ni (cepSnnoCetaerc cepSnoitcennoCI { derahSI ecafretni } ;)(dohteMemos cepSnoitcennoCrehtOI { cepSnoitcennoCI ecafretni } ... { cepSnoitcennoCrehtOI ecafretni :woleb denifed era secafretn Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org X-YMail-OSG: 78_ZVv0VM1mqwGcdF8VQ8AqK69ijslrrY850RyHyWT2U6fbnHti_Jyn61.gapzsy5.EnMncgHDvfjHTuexvucN4oZL4l.Sk0s2OzNpuezCQYZ0JnmnA- Date: Tue, 25 Sep 2007 13:31:18 -0500 From: Paul Calabrese Reply-To: calabrese_p@ociweb.com User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) To: Johnny Willemsen Cc: "'Juergen Boldt'" , issues@omg.org, cxx_revision@omg.org, corba-rtf@omg.org, corba-e-ftf@omg.org Subject: Re: issue 11403 -- Language Mapping issue Johnny Willemsen wrote: This doesn't look to me something for the C++ RTF, more for the general CORBA RTF, but personally I think this is more an application issue, not a CORBA issue. I agree, this is an application issue. In a private email last week, I referred Juergen to this FAQ: http://www.theaceorb.com/faq/index.html#062 I probably should have sent this to the original lists he posted to. -- Paul Calabrese Object Computing Inc. (314) 232-2482 smime6.p7s Cc: "'Juergen Boldt'" , , , , From: Bill Beckwith Subject: Re: issue 11403 -- Language Mapping issue Date: Tue, 25 Sep 2007 14:33:35 -0400 To: "Johnny Willemsen" X-Mailer: Apple Mail (2.752.3) Sorry I wasn't more clear on the scope of shutdown. Shutting down the ORB and the ORB shutting down a failed or otherwise reclaimed communication resource have related semantics so I tend to blend them together in my thinking for "ORB shutdown". Bill On Sep 25, 2007, at 2:17 PM, Johnny Willemsen wrote: Hi Bill, So far as I read this, the reporter asks for a why he can have CORBA objects that are specific to one client connection and when the client goes away abnormally the ORB will destroy the specific objects. I don't read a relationship with ORB shutdown, only with a shutdown of the client. The reporter assumes the ORB can easily detect that the client is dead, he ignores the fact that the underlying transport maybe hasn't that capability and the fact that the ORB can close connections if it likes. Johnny -------------------------------------------------------------------------------- From: Bill Beckwith [mailto:bill.beckwith@ois.com] Sent: Tuesday, September 25, 2007 5:18 PM To: Johnny Willemsen Cc: 'Juergen Boldt'; issues@omg.org; cxx_revision@omg.org; corba-rtf@omg.org; corba-e-ftf@omg.org Subject: Re: issue 11403 -- Language Mapping issue Hi Johnny, This is looks to me like a shortcoming of the implementation of the ORB. Robust shutdown of the ORB is possible with the existing specification. By "robust" I mean that the ORB shutdown process is safe in the presence of multiple threads, does not leave behind pointers to deleted memory, resources are completely reclaimed, et al. Given the ORB doesn't have the robust shutdown semantics then I could see how an application might be structured to release resources in an order required by that ORB. Bill On Sep 25, 2007, at 5:22 AM, Johnny Willemsen wrote: Hi, This doesn't look to me something for the C++ RTF, more for the general CORBA RTF, but personally I think this is more an application issue, not a CORBA issue. Johnny -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, September 14, 2007 5:11 PM To: issues@omg.org; cxx_revision@omg.org; corba-rtf@omg.org; corba-e-ftf@omg.org Subject: issue 11403 -- Language Mapping issue I registered this issue under the C++ RTF From: webmaster@omg.org Date: 14 Sep 2007 08:18:16 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Ou changhua Company: Alcatel-Lucent mailFrom: changhua.ou@alcatel-lucent.com Notification: Yes Specification: C++ Language Mapping Specification Section: 13.6 Server mapping FormalNumber: 03-06-03 Version: 1.1 RevisionDate: June 2003 Page: 1-129 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Description Althrough I report my issue as a C++ issue, actually it is a common issue for other languages also. In current CORBA standard, a activated CORBA Servant object in the POA is shared by all the clients. But in many applications, a client connects to the server and calls some CORBA object methods to create a lot of connection related CORBA objects. Normally, the client will call "destroy" method of these CORBA object to destroy them before existing. But if the client exists abnormally, these created CORBA object will never be destroyed and never be used by any client. We can call this kind of CORBA object as "floating" CORBA object. The CORBA server application runs longer, the "floating" CORBA objects becomes more. And eventually, these "floating" CORBA objects will consume all the memory resources/CPU resources, then the CORBA server crashes and has to be restarted. The "floating" CORBA objects problem at the server side is not easy to be solved. For this problem, if the CORBA standard provides a method to solve it, the CORBA server will run more robust. Actually, the underlying network connection broken can be detected very effectively and rapidly. The CORBA server just simply ignores the network connection lost event and does not pass it to activated CORBA object even if the CORBA object is connection related object because current CORBA standard thinks that all the CORBA objects in the server are shared to all clients. If the server can notify the network connection lost event to the connection related CORBA objects, the developper can do the clean job on it. A simple method can solve the "floating" CORBA object problem. It is not required to add any new interface or data structure to current orb.idl. It is just required to add some new language mapping methods at server side only. I will give an example in C++ to show this simple method. A IShared,IConnSpec and IOtherConnectionSpec i .reve rof dellac eb ton lliw dohtem ")(tsoLnoitcennoc" sti ,noitcennoc yna htiw etacissa ton seod pets )1 eht ni detaerc taht tcejbo lpmIderahS eht esuaceB } ;siht eteled ylpmis tcejbo detaler noitcennoc siht eteled tsuj// { )(tsoLnoitcennoc::cepSnoitcennoCrehtOI_AOP diov } ;siht eteled ylpmis tcejbo detaler noitcennoc siht eteled tsuj// { )(tsoLnoitcennoc::cepSnoitcennoCI_AOP diov :woleb detsil si noitatnemelpmi tluafed sti dna ")(tsoLnoitcennoc" ehT .dohtem ")(tsoLnoitcennoc" rieht llac dna noitcennoc krowten siht htiw detaicossa tcejbo ABROC eht lla dnif dluohs revres ABROC eht ,tsol si noitcennoc krowten eht nehW .tcejbo ABROC yreve rof ")(tsoLnoitcennoc" deman dohtem gnippam wen a dda )5 } ;) siht (_siht>-lpmIcepSnnoCrehto nruter// ? ro// ;) )(txetnoCnoitcennoCteg (_siht>-lpmIcepSnnoCrehto nruter ... ;)...(lpmIcepSnoitcennoCrehtO wen = lpmIcepSnnoCrehto* lpmIcepSnoitcennoCrehtO ... { )(dohteMemos::cepSnoitcennoCI_AOP rtp_cepSnoitcennoCrehtOI :siht ekil tcejbo ABROC detaler noitcennoc rehto yna etavitca dna etaerc nac cepSnoitcennoCI eht ,yaw siht nI ;)(txetnoCnoitcennoCteg::cepSnoitcennoCI_AOP &txetnoCnoitcennoC tsnoc ;)(txetnoCnoitcennoCteg::derahSI &txetnoCnoitcennoC tsnoc .tcejbo ABROC yreve rof ")(txetnoCnoitcennoCteg" deman dohtem gnippam wen a dda )4 ."TXETNOC_NOITCENNOC_ON" elbairav labolg a si txetnoCnoitcennoC eht ,emit siht tA .osla tcejbo derahs a evitca ot dohtem ")xtCnnoc &txetnoCnoitcennoC tsnoc (_siht" eht esu nac resU :etoN .tcejbo derahs fo daetsni tcejbo detaler noitcennoc a semoceb tcejbo ABROC detavitca sihT .tcejbo ABROC eht evitca ot dohtem "")(siht" dlo eht fo daetsni dohtem ")xtCnnoc &txetnoCnoitcennoC tsnoc (_siht" eht sesu resu eht ,dohtem siht ni } ;) xtCnnoc (_siht>-lpmIcepSnnoc nruter dohtem evitca detaler noitcennoc eht esu// ... ;) ... (cepSnoitcennoCI wen = lpmIcepSnnoc* cepSnoitcennoCI ... {) xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc tsnoc (cepSnnoCetaerc::derahSI_AOP rtp_cepSnoitcennoCI :dohtem ") xtCnnoc &txetnoCnoitcennoC tsnoc (_siht" htiw tcejbo eht evitca dna dohtem ") xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc (cepSnnoCetaerc rtp_cepSnoitcennoCI" eht daolrevo tsum ehs/eh ,tcejbo detaler noitcennoc a etaerc ot stnaw resu eht fI )3 } ;) marap (cepSnnoCetaerc nruter senifed dradnats ABROC tnerruc eht ekil xtCnnoc eht erongi tsuj// {) xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc tsnoc (cepSnnoCetaerc::derahSI_AOP rtp_cepSnoitcennoCI :siht ekil noitatnemelpmi tluafed a sah dohtem sihT .dedda si revres dna tneilc eht neewteb noitcennoc eht stneserper taht txetnoCnoitcennoC deman retemarap a ,dohtem siht nI ;) xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc (cepSnnoCetaerc::derahSI_AOP rtp_cepSnoitcennoCI :siht ekil ")(cepSnnoCetaerc::derahSI_AOP" eht rof dohtem gnippam wen dda )2 ;)(siht_.lpmIderahs ... ;) ... (lpmIderahs lpmIderahS :siht ekil detavitca si ti ,stneilc eht lla yb derahs eb lliw derahSI eht )1 .elpmaxe siht ni desu eb lliw secafretni esehT ;} ;) marap gnirts ni (cepSnnoCetaerc cepSnoitcennoCI { derahSI ecafretni } ;)(dohteMemos cepSnoitcennoCrehtOI { cepSnoitcennoCI ecafretni } ... { cepSnoitcennoCrehtOI ecafretni :woleb denifed era secafretn Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: "Johnny Willemsen" To: "'Bill Beckwith'" Cc: "'Juergen Boldt'" , , , , Subject: RE: issue 11403 -- Language Mapping issue Date: Tue, 25 Sep 2007 21:29:05 +0200 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acf/oqflYeWmmJ1ET9i1vm2oseaFOQAB4cfg X-Virus-Scanned: by XS4ALL Virus Scanner X-Spam-Status: No, hits=-0.5 required=5.0 tests=EMAIL_ATTRIBUTION,HTML_10_20,HTML_FONT_COLOR_BLUE, HTML_MESSAGE,IN_REP_TO,MAILTO_LINK,MISSING_OUTLOOK_NAME, REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Hi, When the ORB does I shutdown I agree it should cleanup all objects, but when we loose a connection to a client, and the ORB doesn't shutdown (it is serving other clients), then CORBA doesn't define any standard cleanup (and I think it shouldn't). Johnny -------------------------------------------------------------------------------- From: Bill Beckwith [mailto:bill.beckwith@ois.com] Sent: Tuesday, September 25, 2007 8:34 PM To: Johnny Willemsen Cc: 'Juergen Boldt'; issues@omg.org; cxx_revision@omg.org; corba-rtf@omg.org; corba-e-ftf@omg.org Subject: Re: issue 11403 -- Language Mapping issue Sorry I wasn't more clear on the scope of shutdown. Shutting down the ORB and the ORB shutting down a failed or otherwise reclaimed communication resource have related semantics so I tend to blend them together in my thinking for "ORB shutdown". Bill On Sep 25, 2007, at 2:17 PM, Johnny Willemsen wrote: Hi Bill, So far as I read this, the reporter asks for a why he can have CORBA objects that are specific to one client connection and when the client goes away abnormally the ORB will destroy the specific objects. I don't read a relationship with ORB shutdown, only with a shutdown of the client. The reporter assumes the ORB can easily detect that the client is dead, he ignores the fact that the underlying transport maybe hasn't that capability and the fact that the ORB can close connections if it likes. Johnny -------------------------------------------------------------------------------- From: Bill Beckwith [mailto:bill.beckwith@ois.com] Sent: Tuesday, September 25, 2007 5:18 PM To: Johnny Willemsen Cc: 'Juergen Boldt'; issues@omg.org; cxx_revision@omg.org; corba-rtf@omg.org; corba-e-ftf@omg.org Subject: Re: issue 11403 -- Language Mapping issue Hi Johnny, This is looks to me like a shortcoming of the implementation of the ORB. Robust shutdown of the ORB is possible with the existing specification. By "robust" I mean that the ORB shutdown process is safe in the presence of multiple threads, does not leave behind pointers to deleted memory, resources are completely reclaimed, et al. Given the ORB doesn't have the robust shutdown semantics then I could see how an application might be structured to release resources in an order required by that ORB. Bill On Sep 25, 2007, at 5:22 AM, Johnny Willemsen wrote: Hi, This doesn't look to me something for the C++ RTF, more for the general CORBA RTF, but personally I think this is more an application issue, not a CORBA issue. Johnny -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, September 14, 2007 5:11 PM To: issues@omg.org; cxx_revision@omg.org; corba-rtf@omg.org; corba-e-ftf@omg.org Subject: issue 11403 -- Language Mapping issue I registered this issue under the C++ RTF From: webmaster@omg.org Date: 14 Sep 2007 08:18:16 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Ou changhua Company: Alcatel-Lucent mailFrom: changhua.ou@alcatel-lucent.com Notification: Yes Specification: C++ Language Mapping Specification Section: 13.6 Server mapping FormalNumber: 03-06-03 Version: 1.1 RevisionDate: June 2003 Page: 1-129 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Description Althrough I report my issue as a C++ issue, actually it is a common issue for other languages also. In current CORBA standard, a activated CORBA Servant object in the POA is shared by all the clients. But in many applications, a client connects to the server and calls some CORBA object methods to create a lot of connection related CORBA objects. Normally, the client will call "destroy" method of these CORBA object to destroy them before existing. But if the client exists abnormally, these created CORBA object will never be destroyed and never be used by any client. We can call this kind of CORBA object as "floating" CORBA object. The CORBA server application runs longer, the "floating" CORBA objects becomes more. And eventually, these "floating" CORBA objects will consume all the memory resources/CPU resources, then the CORBA server crashes and has to be restarted. The "floating" CORBA objects problem at the server side is not easy to be solved. For this problem, if the CORBA standard provides a method to solve it, the CORBA server will run more robust. Actually, the underlying network connection broken can be detected very effectively and rapidly. The CORBA server just simply ignores the network connection lost event and does not pass it to activated CORBA object even if the CORBA object is connection related object because current CORBA standard thinks that all the CORBA objects in the server are shared to all clients. If the server can notify the network connection lost event to the connection related CORBA objects, the developper can do the clean job on it. A simple method can solve the "floating" CORBA object problem. It is not required to add any new interface or data structure to current orb.idl. It is just required to add some new language mapping methods at server side only. I will give an example in C++ to show this simple method. A IShared,IConnSpec and IOtherConnectionSpec i .reve rof dellac eb ton lliw dohtem ")(tsoLnoitcennoc" sti ,noitcennoc yna htiw etacissa ton seod pets )1 eht ni detaerc taht tcejbo lpmIderahS eht esuaceB } ;siht eteled ylpmis tcejbo detaler noitcennoc siht eteled tsuj// { )(tsoLnoitcennoc::cepSnoitcennoCrehtOI_AOP diov } ;siht eteled ylpmis tcejbo detaler noitcennoc siht eteled tsuj// { )(tsoLnoitcennoc::cepSnoitcennoCI_AOP diov :woleb detsil si noitatnemelpmi tluafed sti dna ")(tsoLnoitcennoc" ehT .dohtem ")(tsoLnoitcennoc" rieht llac dna noitcennoc krowten siht htiw detaicossa tcejbo ABROC eht lla dnif dluohs revres ABROC eht ,tsol si noitcennoc krowten eht nehW .tcejbo ABROC yreve rof ")(tsoLnoitcennoc" deman dohtem gnippam wen a dda )5 } ;) siht (_siht>-lpmIcepSnnoCrehto nruter// ? ro// ;) )(txetnoCnoitcennoCteg (_siht>-lpmIcepSnnoCrehto nruter ... ;)...(lpmIcepSnoitcennoCrehtO wen = lpmIcepSnnoCrehto* lpmIcepSnoitcennoCrehtO ... { )(dohteMemos::cepSnoitcennoCI_AOP rtp_cepSnoitcennoCrehtOI :siht ekil tcejbo ABROC detaler noitcennoc rehto yna etavitca dna etaerc nac cepSnoitcennoCI eht ,yaw siht nI ;)(txetnoCnoitcennoCteg::cepSnoitcennoCI_AOP &txetnoCnoitcennoC tsnoc ;)(txetnoCnoitcennoCteg::derahSI &txetnoCnoitcennoC tsnoc .tcejbo ABROC yreve rof ")(txetnoCnoitcennoCteg" deman dohtem gnippam wen a dda )4 ."TXETNOC_NOITCENNOC_ON" elbairav labolg a si txetnoCnoitcennoC eht ,emit siht tA .osla tcejbo derahs a evitca ot dohtem ")xtCnnoc &txetnoCnoitcennoC tsnoc (_siht" eht esu nac resU :etoN .tcejbo derahs fo daetsni tcejbo detaler noitcennoc a semoceb tcejbo ABROC detavitca sihT .tcejbo ABROC eht evitca ot dohtem "")(siht" dlo eht fo daetsni dohtem ")xtCnnoc &txetnoCnoitcennoC tsnoc (_siht" eht sesu resu eht ,dohtem siht ni } ;) xtCnnoc (_siht>-lpmIcepSnnoc nruter dohtem evitca detaler noitcennoc eht esu// ... ;) ... (cepSnoitcennoCI wen = lpmIcepSnnoc* cepSnoitcennoCI ... {) xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc tsnoc (cepSnnoCetaerc::derahSI_AOP rtp_cepSnoitcennoCI :dohtem ") xtCnnoc &txetnoCnoitcennoC tsnoc (_siht" htiw tcejbo eht evitca dna dohtem ") xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc (cepSnnoCetaerc rtp_cepSnoitcennoCI" eht daolrevo tsum ehs/eh ,tcejbo detaler noitcennoc a etaerc ot stnaw resu eht fI )3 } ;) marap (cepSnnoCetaerc nruter senifed dradnats ABROC tnerruc eht ekil xtCnnoc eht erongi tsuj// {) xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc tsnoc (cepSnnoCetaerc::derahSI_AOP rtp_cepSnoitcennoCI :siht ekil noitatnemelpmi tluafed a sah dohtem sihT .dedda si revres dna tneilc eht neewteb noitcennoc eht stneserper taht txetnoCnoitcennoC deman retemarap a ,dohtem siht nI ;) xtCnnoc &txetnoCnoitcennoC tsnoc ,marap *rahc (cepSnnoCetaerc::derahSI_AOP rtp_cepSnoitcennoCI :siht ekil ")(cepSnnoCetaerc::derahSI_AOP" eht rof dohtem gnippam wen dda )2 ;)(siht_.lpmIderahs ... ;) ... (lpmIderahs lpmIderahS :siht ekil detavitca si ti ,stneilc eht lla yb derahs eb lliw derahSI eht )1 .elpmaxe siht ni desu eb lliw secafretni esehT ;} ;) marap gnirts ni (cepSnnoCetaerc cepSnoitcennoCI { derahSI ecafretni } ;)(dohteMemos cepSnoitcennoCrehtOI { cepSnoitcennoCI ecafretni } ... { cepSnoitcennoCrehtOI ecafretni :woleb denifed era secafretn Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org