[omniORB] omniorb 4.1.3 and large messages

[Michael]

No (at least not with omniORB), and that doesn't only happen in the
server but potentially in the client. Why would you want to use fixed
sze arrays anyway? There is no penalty for using sequences and they're
much safer to use anyway (its a little bit C++ array vs. std::vector).

Will Denissen wrote:
> ________________________________
> 
> Van: Michael [mailto:omniorb at bindone.de]
> Verzonden: do 22-1-2009 15:26
> Aan: Will Denissen; 'omniorb-list at omniorb-support.com'
> Onderwerp: Re: [omniORB] omniorb 4.1.3 and large messages
> 
> 
> 
> You can change giopMaxMsgSize in omniORB.cfg to a higher value. You
> 
> 
>  
> The giopMaxMsgSize is the limit for which omniorb will throw a CORBA::MARSHAL exception.
> So raising the value would only make the DIM range of unkown behaviour larger.
> 
> shouldn't use arrays, because they are allocated on the stack (therefore
> 
> Is there an possibility/option to let the server allocate on the heap? It would probably solve these kinds of problems.
> 
> 
> I would assume the different exceptions), use a sequence instead
> (typedef sequence<octet> OctSeq)
> 
> I am not in the position to modify types.
> 
> Will Denissen wrote:
>> Dear Duncan,
>>
>> I have modified the standard echo example into
>> one simple function st_fi with one inout parameter of a big fixed size
>> structure type.
>>
>> Depending on the size of the dimension DIM, the client and server react
>> differently (see echo.idl)
>>
>> --- echo.idl
>> ------------------------------------------------------------------------
>> ------
>> //                                     Client:                 Server:
>>
>> //const long DIM = 2097152; //  2MB   CORBA::MARSHAL         OK
>> //const long DIM = 2097100; //        CORBA::MARSHAL         OK
>> //const long DIM = 2097000; //        CORBA::COMM_FAILURE
>> Segmentation Fault after a while
>> //const long DIM = 1100000; //        CORBA::COMM_FAILURE
>> Segmentation Fault after a while
>> //const long DIM = 1048576; //  1MB   sys exc TRANSIENT
>> Segmentation Fault after a while
>> //const long DIM = 1000000; //        OK                     OK
>>
>> const long   DIM = 1048576;
>>
>> struct st_fi_t {
>>   octet x[DIM];
>> };
>>
>> interface Echo {
>>   void st_fi(inout st_fi_t p1);
>> };
>>
>> --- end of echo.idl
>> ------------------------------------------------------------------------
>>
>>
>> Have you any idea why omniorb is reacting like this?
>> How do I know what the exact bounderies are that will give a robust
>> correctly working omniorb?
>> Is it possible to build in extra checks into omniorb to prevent/detect
>> this kind of unwanted behaviour?
>>
>> PS:
>> If you need to reproduce the results.
>> The server implementation of st_fi is just empty (see serv.cc).
>> The client just calls st_fi once with it parameter allocated on the heap
>> (see clnt.cc)
>> The executables are build and started with (makefile, start_client,
>> start_server).
>> The used options file is sample.cfg.
>> I am using omniorb 4.1.3 on Solaris 5.8 and gcc 4.1.2
>>
>> Will.
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> omniORB-list mailing list
>> omniORB-list at omniorb-support.com
>> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list