One of my Corba operations is returning a sequence of a sequence (a two-dimensional array) of an union type.
In a test it turned out this operation can’t handle more than 32 kB of data returned at once. If overall array size exceeds 32 kB, response on client side only gets correctly unmarshalled up to 32 kB. From that point on, it is populated by uninitialized data (that eventually make unmarshaling fail).
In the same environment, there are other operations that are able to return data of larger sizes. This is however the only operation that returns a sequence of a sequence.
Is there a limitation of length of sequences or data in general transferred over Corba that I should be aware of?
My environment consists of a 32-bit Java 6 client (using standard Java ORB) and a 64-bit server (C, with 2AB ORB implementation).
I’ve tried so far:
Tweaked several Orb properties on both client and server side, that seemed related – timeout settings (transport.ORBTCPReadTimeout – timeout set to a large number), GIOP settings (giop.ORBFragmentSize, giop.ORBBufferSize – both set to large numbers). None of these settings changed the behavior.
Using a packet sniffer, I could confirm data were sent to the client. The problem occurs during unmarshaling.
CORBA unbounded sequences are, in fact bounded a little bit – but not enough that you should have noticed it.
They are marshalled as an unsigned long (or in CORBA terms, a
CORBA::ULong) which tells the marshalling engine how many occurrences of each element will be coming next down the wire. It should always be able to contain up to 2,147,483,647 elements (that’s 2^32, the size of aCORBA::ULong). That’s a whole lot more than 32kb, so it sounds like your ORB has a bug.In addition, the fact that it’s silently failing by filling it in partially rather than throwing a
CORBA::MARSHALexception is pretty bad. Tell your ORB vendor to start testing for the basics.