[omniORB] Array size limit

[Klas Nordberg]

Hi

I'm testing how long time it takes to send large arrays of bytes
(CORBA::Octet) between a server and client using omniORB CORBA by
writing a client which sends 10^6 bytes to a server which just copies
the received byte array to a local buffer.

On a linux platform this works fine, but when I tested to run the client
on a Windows platform, I get a stack overflow runtime error (not an
exception) from somewhere deep in the ORB. When I decrease the size of
the array, however, it works. Apparently, there is a limit on the
amount of data in an array which can be processed by the ORB.

The idl looks like

typedef octet inputdata[1000000];

interface server {
long receivedata(in inputdata data);
};


QUESTION1: Can I increase the limit so that a 10^6 byte array can be
sent in one chunk also from a Windows client? Is there a configuration
variable?

QUESTION2: Is this limit documented somewhere? Is it a bug? It appears
to me that the stack overflow error is not gracefully managed by the ORB

Regards

Klas Nordberg

[evgeni.rojkov at durr.com ()]

Here is part from omniOrb.cfg
Is this what you are looking for?
Kind Regards, Evgeni
....
############################################################################
# giopMaxMsgSize
#
# This value defines the ORB-wide limit on the size of GIOP message
# (excluding the header). If this limit is exceeded, the ORB will
# refuse to send or receive the message and raise a MARSHAL exception.
#
# Valid values = (n >= 8192)
#
giopMaxMsgSize = 2097152 # 2 MBytes.
....

-----Urspr?ngliche Nachricht-----
Von: omniorb-list-***@omniorb-support.com
[mailto:omniorb-list-***@omniorb-support.com] Im Auftrag von Klas Nordberg
Gesendet: Mittwoch, 7. Mai 2008 10:29
An: omniorb-***@omniorb-support.com
Betreff: [omniORB] Array size limit


Hi

I'm testing how long time it takes to send large arrays of bytes
(CORBA::Octet) between a server and client using omniORB CORBA by
writing a client which sends 10^6 bytes to a server which just copies
the received byte array to a local buffer.

On a linux platform this works fine, but when I tested to run the client
on a Windows platform, I get a stack overflow runtime error (not an
exception) from somewhere deep in the ORB. When I decrease the size of
the array, however, it works. Apparently, there is a limit on the
amount of data in an array which can be processed by the ORB.

The idl looks like

typedef octet inputdata[1000000];

interface server {
long receivedata(in inputdata data);
};


QUESTION1: Can I increase the limit so that a 10^6 byte array can be
sent in one chunk also from a Windows client? Is there a configuration
variable?

QUESTION2: Is this limit documented somewhere? Is it a bug? It appears
to me that the stack overflow error is not gracefully managed by the ORB

Regards

Klas Nordberg

[BaileyK at schneider.com ()]

I suspect the use of a fixed size array is causing the marshalling code to
try to allocate it on the stack, and it's too big. The orb configuration
wouldn't help in that case.

Try using sequence<octet> rather than a fixed size array.


---
Kendall Bailey
Engineering & Research

Post by evgeni.rojkov at durr.com ()
Here is part from omniOrb.cfg
Is this what you are looking for?
Kind Regards, Evgeni
....

############################################################################

Post by evgeni.rojkov at durr.com ()
# giopMaxMsgSize
#
# This value defines the ORB-wide limit on the size of GIOP message
# (excluding the header). If this limit is exceeded, the ORB will
# refuse to send or receive the message and raise a MARSHAL exception.
#
# Valid values = (n >= 8192)
#
giopMaxMsgSize = 2097152 # 2 MBytes.
....
-----Urspr?ngliche Nachricht-----

Nordberg

Post by evgeni.rojkov at durr.com ()
Gesendet: Mittwoch, 7. Mai 2008 10:29
Betreff: [omniORB] Array size limit
Hi
I'm testing how long time it takes to send large arrays of bytes
(CORBA::Octet) between a server and client using omniORB CORBA by
writing a client which sends 10^6 bytes to a server which just copies
the received byte array to a local buffer.
On a linux platform this works fine, but when I tested to run the client
on a Windows platform, I get a stack overflow runtime error (not an
exception) from somewhere deep in the ORB. When I decrease the size of
the array, however, it works. Apparently, there is a limit on the
amount of data in an array which can be processed by the ORB.
The idl looks like
typedef octet inputdata[1000000];
interface server {
long receivedata(in inputdata data);
};
QUESTION1: Can I increase the limit so that a 10^6 byte array can be
sent in one chunk also from a Windows client? Is there a configuration
variable?
QUESTION2: Is this limit documented somewhere? Is it a bug? It appears
to me that the stack overflow error is not gracefully managed by the ORB
Regards
Klas Nordberg

[Bruce Visscher]

See also, omni_thread::stacksize() and omni_thread::stacksize(unsigned long).

Post by BaileyK at schneider.com ()
I suspect the use of a fixed size array is causing the marshalling code to
try to allocate it on the stack, and it's too big. The orb configuration
wouldn't help in that case.
Try using sequence<octet> rather than a fixed size array.
---
Kendall Bailey
Engineering & Research

Post by evgeni.rojkov at durr.com ()
Here is part from omniOrb.cfg
Is this what you are looking for?
Kind Regards, Evgeni
....

############################################################################

Post by evgeni.rojkov at durr.com ()
# giopMaxMsgSize
#
# This value defines the ORB-wide limit on the size of GIOP message
# (excluding the header). If this limit is exceeded, the ORB will
# refuse to send or receive the message and raise a MARSHAL exception.
#
# Valid values = (n >= 8192)
#
giopMaxMsgSize = 2097152 # 2 MBytes.
....
-----Urspr?ngliche Nachricht-----

Nordberg

Post by evgeni.rojkov at durr.com ()
Gesendet: Mittwoch, 7. Mai 2008 10:29
Betreff: [omniORB] Array size limit
Hi
I'm testing how long time it takes to send large arrays of bytes
(CORBA::Octet) between a server and client using omniORB CORBA by
writing a client which sends 10^6 bytes to a server which just copies
the received byte array to a local buffer.
On a linux platform this works fine, but when I tested to run the client
on a Windows platform, I get a stack overflow runtime error (not an
exception) from somewhere deep in the ORB. When I decrease the size of
the array, however, it works. Apparently, there is a limit on the
amount of data in an array which can be processed by the ORB.
The idl looks like
typedef octet inputdata[1000000];
interface server {
long receivedata(in inputdata data);
};
QUESTION1: Can I increase the limit so that a 10^6 byte array can be
sent in one chunk also from a Windows client? Is there a configuration
variable?
QUESTION2: Is this limit documented somewhere? Is it a bug? It appears
to me that the stack overflow error is not gracefully managed by the ORB
Regards
Klas Nordberg

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

[Duncan Grisby]

Post by Klas Nordberg
I'm testing how long time it takes to send large arrays of bytes
(CORBA::Octet) between a server and client using omniORB CORBA by
writing a client which sends 10^6 bytes to a server which just copies
the received byte array to a local buffer.
On a linux platform this works fine, but when I tested to run the
client on a Windows platform, I get a stack overflow runtime error
(not an exception) from somewhere deep in the ORB. When I decrease
the size of the array, however, it works. Apparently, there is a
limit on the amount of data in an array which can be processed by the
ORB.

The C++ mapping for arrays places the array on the stack, and you're
just running out of stack space. There's not a whole lot omniORB can do
about that. You can increase the stack size omniORB uses for each
thread, by setting the omni_thread::stacksize() static function, but
that will only make the problem occur at larger sizes.

A better idea is to use a sequence<octet>, since the C++ mapping puts
the data on the heap, and thus isn't limited to stack size.

Cheers,

Duncan.