[omniORB] omniorb 4.1.3 and large messages

[Bruce Visscher]

Will,

You don't say what platform this is but omniORB does things in threads.  I
would assume other ORBs do too.  It is generally a bad idea to use large
arrays in threads because they likely have limited stack space.  Try
changing your example to use a sequence<octet>.
Bruce

On Thu, Jan 22, 2009 at 9:26 AM, Michael <omniorb at bindone.de> wrote:

> You can change giopMaxMsgSize in omniORB.cfg to a higher value. You
> shouldn't use arrays, because they are allocated on the stack (therefore
> I would assume the different exceptions), use a sequence instead
> (typedef sequence<octet> OctSeq)
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20090122/e509eae2/attachment-0001.htm