[omniORB] omniorb 4.1.3 and large messages

[Will Denissen]

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: echo.idl
Type: application/octet-stream
Size: 623 bytes
Desc: echo.idl
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20090122/6d14dd21/echo-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clnt.cc
Type: application/octet-stream
Size: 1227 bytes
Desc: clnt.cc
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20090122/6d14dd21/clnt-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: serv.cc
Type: application/octet-stream
Size: 2643 bytes
Desc: serv.cc
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20090122/6d14dd21/serv-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: makefile
Type: application/octet-stream
Size: 736 bytes
Desc: makefile
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20090122/6d14dd21/makefile-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sample.cfg
Type: application/octet-stream
Size: 41665 bytes
Desc: sample.cfg
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20090122/6d14dd21/sample-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: start_client
Type: application/octet-stream
Size: 199 bytes
Desc: start_client
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20090122/6d14dd21/start_client-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: start_server
Type: application/octet-stream
Size: 195 bytes
Desc: start_server
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20090122/6d14dd21/start_server-0001.obj

[Michael]

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)

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
------------------------------------------------------------------------
------
//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?
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
http://www.omniorb-support.com/mailman/listinfo/omniorb-list

[Will Denissen]

________________________________

Van: Michael [mailto:***@bindone.de]
Verzonden: do 22-1-2009 15:26
Aan: Will Denissen; 'omniorb-***@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.

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
------------------------------------------------------------------------
------
//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?
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
http://www.omniorb-support.com/mailman/listinfo/omniorb-list

[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).

________________________________
Verzonden: do 22-1-2009 15:26
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.

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
------------------------------------------------------------------------
------
//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?
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
http://www.omniorb-support.com/mailman/listinfo/omniorb-list

------------------------------------------------------------------------
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list

[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

Post by Michael
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)

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
------------------------------------------------------------------------
------
//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?
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
http://www.omniorb-support.com/mailman/listinfo/omniorb-list

_______________________________________________
omniORB-list mailing list
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

[Duncan Grisby]

Post by Will Denissen

Post by Michael
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.

The standard C++ mapping for arrays says they should be on the stack.
omniORB can't allocate them on the heap. Basically, large IDL arrays
don't work with the C++ mapping.

You could, of course, modify omniORB to put arrays on the stack, but
that would make it incompatible with the standard mapping.

As others have said, it's far better to use sequences if you have large
data items.

Cheers,

Duncan.