RE: [mico-devel] Remote method call Time-out
Hi, I am using the latest snapshot of mico (2008-03-19). I could not found the parameter you have suggested. But I have found a way to achieve the desired result by using Request Time Out policy with policy manager (i.e by creating the timeout policy with RELATIVE_RT_TIMEOUT_POLICY_TYPE and setting the timeout value). I get proper TimeOut exceptions when I unplug the client's network cable after few calls to the server. The problem I am facing now is that the ORB crashes if I continue to make calls on the broken network for another 10 mins. Though I get TimeOut exceptions for all such calls, but after 10 mins the ORB crashes inadvertently. The only line I get in the trace is iop.cc:3435: failed assertion `0' P.S: I have tested this on Mac and windows with the timeout policy samples given with the mico ORB. On windows it crashes just after unplugging the cable and on Mac the crash happens after 10 mins. I would be obliged if you can provide any help or direction on this. Regards Ashish From: rssh [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 22, 2008 7:46 PM To: Ashish Kumar Sharma; mico-devel@mico.org Subject: Re: [mico-devel] Remote method call Time-out On Tue, 22 Apr 2008 17:09:22 +0530, Ashish Kumar Sharma wrote Hi, I have a requirement to use remote method call time-out functionality when using mico ORB on the client side. I am using the latest snapshot dated 19-03-2008. Can you please advice me on how to achieve this. I remember that I patched mico to add -ORBCallTimeout option in 2004 Hope, this still must work. Regards, Ashish Kumar Sharma Sr. Software Engineer Enterprise - RD www.quark.com CONFIDENTIALITY NOTICE This e-mail transmission and any documents, files, or previous e-mail messages appended or attached to it, may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, printing, distribution, or use of the information contained or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone (172.229.9460) or return e-mail message ([EMAIL PROTECTED]) and delete the original transmission, its attachments, and any copies without reading or saving in any manner. Thank you. -- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
RE: [mico-devel] Remote method call Time-out
Oh.. it's at iop.cc:3423 in the function void MICO::IIOPProxy::abort_invoke (CORBA::ORBMsgId id) I haven't done any modifications to the code. thanks Regards Ashish -Original Message- From: Karel Gardas [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 23, 2008 6:01 PM To: Ashish Kumar Sharma Cc: rssh; mico-devel@mico.org Subject: RE: [mico-devel] Remote method call Time-out Hi, I'm not able to find any assert on the iop.cc:3435. Have you modified the code? If so, how do your changes look? Cheers, Karel Ashish Kumar Sharma wrote: Hi, I am using the latest snapshot of mico (2008-03-19). I could not found the parameter you have suggested. But I have found a way to achieve the desired result by using Request Time Out policy with policy manager (i.e by creating the timeout policy with RELATIVE_RT_TIMEOUT_POLICY_TYPE and setting the timeout value). I get proper TimeOut exceptions when I unplug the client's network cable after few calls to the server. The problem I am facing now is that the ORB crashes if I continue to make calls on the broken network for another 10 mins. Though I get TimeOut exceptions for all such calls, but after 10 mins the ORB crashes inadvertently. The only line I get in the trace is iop.cc:3435: failed assertion `0' P.S: I have tested this on Mac and windows with the timeout policy samples given with the mico ORB. On windows it crashes just after unplugging the cable and on Mac the crash happens after 10 mins. I would be obliged if you can provide any help or direction on this. Regards Ashish From: rssh [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 22, 2008 7:46 PM To: Ashish Kumar Sharma; mico-devel@mico.org Subject: Re: [mico-devel] Remote method call Time-out On Tue, 22 Apr 2008 17:09:22 +0530, Ashish Kumar Sharma wrote Hi, I have a requirement to use remote method call time-out functionality when using mico ORB on the client side. I am using the latest snapshot dated 19-03-2008. Can you please advice me on how to achieve this. I remember that I patched mico to add -ORBCallTimeout option in 2004 Hope, this still must work. Regards, Ashish Kumar Sharma Sr. Software Engineer Enterprise - RD www.quark.com CONFIDENTIALITY NOTICE This e-mail transmission and any documents, files, or previous e-mail messages appended or attached to it, may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, printing, distribution, or use of the information contained or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone (172.229.9460) or return e-mail message ([EMAIL PROTECTED]) and delete the original transmission, its attachments, and any copies without reading or saving in any manner. Thank you. ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
[mico-devel] Remote method call Time-out
Hi, I have a requirement to use remote method call time-out functionality when using mico ORB on the client side. I am using the latest snapshot dated 19-03-2008. Can you please advice me on how to achieve this. Regards, Ashish Kumar Sharma Sr. Software Engineer Enterprise - RD www.quark.com CONFIDENTIALITY NOTICE This e-mail transmission and any documents, files, or previous e-mail messages appended or attached to it, may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, printing, distribution, or use of the information contained or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone (172.229.9460) or return e-mail message ([EMAIL PROTECTED]) and delete the original transmission, its attachments, and any copies without reading or saving in any manner. Thank you. image001.gif___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
[mico-devel] Symbol Conflict on MacOS X.
Hi All, I am not sure if this is an issue to be posted here but I am completely stuck and would appreciate any help over this. My C++ application (on Mac OS X version 10.4.11) makes use of omni ORB (4.1.0) and Mico (2.3.12) shared libraries. Omni ORB libraries are dependencies of a static library(X.a) linked into the application and mico libraries are dependencies of a dynamically loaded shared library(Y.dylib). The problem is that I get a runtime conflict for some symbols defined in mico and omni libraries. My Y.dylib inadvertently links to wrong function definitions, those defined in omni libraries instead of the definitions in the mico library. The symbols in conflict are (CORBA::DefaultRefCountBase::_add_ref CORBA::DefaultRefCountBase::_remove_ref). omni and mico libraries, both have been built on my machine using gcc version 4.0.1 (build 5367). Regards, Ashish Kumar Sharma Sr. Software Engineer Enterprise - RD www.quark.com CONFIDENTIALITY NOTICE This e-mail transmission and any documents, files, or previous e-mail messages appended or attached to it, may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, printing, distribution, or use of the information contained or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone (172.229.9460) or return e-mail message ([EMAIL PROTECTED]) and delete the original transmission, its attachments, and any copies without reading or saving in any manner. Thank you. image001.gif___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
RE: [mico-devel] Symbol Conflict on MacOS X.
Karel, My application is not linking to the ORB libraries directly, only the application's dependencies (X.a and Y.dylib) link to ORB libraries. So I don't get any compilation or linking errors when I build my application. Even at run time, references to all of the symbols (other than those listed below) are resolved correctly by the dynamic link editor. Just In case if the following gives you some idea (for the solution): The nm dump of the imported symbols in Y.dylib (for a class CORBA::LocalObject in libmico2.3.12.dylib) gives me: (undefined) external __ZN5CORBA11LocalObject11_remove_refEv (from libmico2.3.12) (undefined) external __ZN5CORBA11LocalObject8_add_refEv (from libmico2.3.12) As you see there is proper recording done by the linker for where the dyld should look for symbols at run time. So No conflict for this symbol. Unfortunately, for the symbols CORBA::DefaultValueRefCountBase::_add_ref CORBA::DefaultRefCountBase::_remove_ref, It seems no such recording is being done by the linker. Here is the nm dump for these symbols in Y.dylib: (undefined) weak external __ZN5CORBA24DefaultValueRefCountBase8_add_refEv (undefined) weak external __ZN5CORBA24DefaultValueRefCountBase8_add_refEv.eh (undefined) weak external __ZN5CORBA24DefaultValueRefCountBase11_remove_refEv (undefined) weak external __ZN5CORBA24DefaultValueRefCountBase11_remove_refEv.eh I think the problem lies with the linker's treatment for these symbols. But now sure why with these symbols alone... Regards Ashish -Original Message- From: Karel Gardas [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2008 6:52 PM To: Ashish Kumar Sharma Cc: mico-devel@mico.org Subject: Re: [mico-devel] Symbol Conflict on MacOS X. Hi, I'm afraid that you will need to choose one of your ORBs and use this. Still it's interesting how you solved conflicts in various other symbols which all need to be defined by both ORBs, e.g. CORBA::ORB*, PortableServer::* etc. Cheers, Karel Ashish Kumar Sharma wrote: Hi All, I am not sure if this is an issue to be posted here but I am completely stuck and would appreciate any help over this. My C++ application (on Mac OS X version 10.4.11) makes use of omni ORB (4.1.0) and Mico (2.3.12) shared libraries. Omni ORB libraries are dependencies of a static library(X.a) linked into the application and mico libraries are dependencies of a dynamically loaded shared library(Y.dylib). The problem is that I get a runtime conflict for some symbols defined in mico and omni libraries. My Y.dylib inadvertently links to wrong function definitions, those defined in omni libraries instead of the definitions in the mico library. The symbols in conflict are (CORBA::DefaultRefCountBase::_add_ref CORBA::DefaultRefCountBase::_remove_ref). omni and mico libraries, both have been built on my machine using gcc version 4.0.1 (build 5367). Regards, Ashish Kumar Sharma Sr. Software Engineer Enterprise - RD www.quark.com CONFIDENTIALITY NOTICE This e-mail transmission and any documents, files, or previous e-mail messages appended or attached to it, may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, printing, distribution, or use of the information contained or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone (172.229.9460) or return e-mail message ([EMAIL PROTECTED]) and delete the original transmission, its attachments, and any copies without reading or saving in any manner. Thank you. ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
