<HTML dir=ltr><HEAD><TITLE>Re: [omniORB] omniorb 4.1.3 and large messages</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.6000.16788" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText48489 dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>Van:</B> Michael [mailto:omniorb@bindone.de]<BR><B>Verzonden:</B> do 22-1-2009 15:26<BR><B>Aan:</B> Will Denissen; 'omniorb-list@omniorb-support.com'<BR><B>Onderwerp:</B> Re: [omniORB] omniorb 4.1.3 and large messages<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>You can change giopMaxMsgSize in omniORB.cfg to a higher value. You<BR></P>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#0000ff size=2>The giopMaxMsgSize is the limit for which omniorb will throw a CORBA::MARSHAL exception.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#0000ff>So raising the value would only make the DIM range of unkown behaviour larger.</FONT></DIV>
<P>shouldn't use arrays, because they are allocated on the stack (therefore</P>
<P></FONT><FONT color=#0000ff><FONT face=Arial size=2>Is there an possibility/option to let the server allocate on the heap? </FONT><FONT face=Arial size=2>It would probably solve these kinds of problems.</FONT></FONT></P></DIV><FONT face=Arial size=2></FONT><FONT size=2>
<P><BR>I would assume the different exceptions), use a sequence instead<BR>(typedef sequence<octet> OctSeq)</P>
<P><FONT face=Arial color=#0000ff>I am not in the position to modify types.<BR></FONT><BR>Will Denissen wrote:<BR>> Dear Duncan,<BR>> <BR>> I have modified the standard echo example into<BR>> one simple function st_fi with one inout parameter of a big fixed size<BR>> structure type.<BR>> <BR>> Depending on the size of the dimension DIM, the client and server react<BR>> differently (see echo.idl)<BR>> <BR>> --- echo.idl<BR>> ------------------------------------------------------------------------<BR>> ------<BR>> // Client: Server:<BR>> <BR>> //const long DIM = 2097152; // 2MB CORBA::MARSHAL OK<BR>> //const long DIM = 2097100; // CORBA::MARSHAL OK<BR>> //const long DIM = 2097000; // CORBA::COMM_FAILURE<BR>> Segmentation Fault after a while<BR>> //const long DIM = 1100000; // CORBA::COMM_FAILURE<BR>> Segmentation Fault after a while<BR>> //const long DIM = 1048576; // 1MB sys exc TRANSIENT<BR>> Segmentation Fault after a while<BR>> //const long DIM = 1000000; // OK OK<BR>> <BR>> const long DIM = 1048576;<BR>> <BR>> struct st_fi_t {<BR>> octet x[DIM];<BR>> };<BR>> <BR>> interface Echo {<BR>> void st_fi(inout st_fi_t p1);<BR>> };<BR>><BR>> --- end of echo.idl<BR>> ------------------------------------------------------------------------<BR>> <BR>> <BR>> Have you any idea why omniorb is reacting like this?<BR>> How do I know what the exact bounderies are that will give a robust<BR>> correctly working omniorb?<BR>> Is it possible to build in extra checks into omniorb to prevent/detect<BR>> this kind of unwanted behaviour?<BR>> <BR>> PS:<BR>> If you need to reproduce the results.<BR>> The server implementation of st_fi is just empty (see serv.cc).<BR>> The client just calls st_fi once with it parameter allocated on the heap<BR>> (see clnt.cc)<BR>> The executables are build and started with (makefile, start_client,<BR>> start_server).<BR>> The used options file is sample.cfg.<BR>> I am using omniorb 4.1.3 on Solaris 5.8 and gcc 4.1.2<BR>> <BR>> Will.<BR>> <BR>><BR>><BR>><BR>><BR>> ------------------------------------------------------------------------<BR>><BR>> _______________________________________________<BR>> omniORB-list mailing list<BR>> omniORB-list@omniorb-support.com<BR>> <A href="http://www.omniorb-support.com/mailman/listinfo/omniorb-list">http://www.omniorb-support.com/mailman/listinfo/omniorb-list</A><BR><BR></P></FONT><br clear=all> --
The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. Unless explicitly stated otherwise in the body of this communication or the attachment thereto (if any), the information is provided on an AS-IS basis without any express or implied warranties or liabilities. To the extent you are relying on this information, you are doing so at your own risk. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. ASML is neither liable for the proper and complete transmission of the information contained in this communication, nor for any delay in its receipt.
</BODY></HTML>