[tao-users] ORB maximum data transfer size

[omid shahraki]

Hi guys,

GIOP supports message size up to 4Gb plus fragmentation in version 1.1. You
can check GIOP header documentation for more info.

Bests,
Omid Shahraki
On 30 Aug 2016 11:09, "Phil Mesnier" <mesnierp at ociweb.com> wrote:

> Hi Siddharth,
>
> > On Aug 29, 2016, at 8:03 AM, Siddharth Kulkarni <sidd.kulkarni at gmail.com>
> wrote:
> >
> > OK Thanks for the information.
> > What we have observed that our JacORB client gets hang if we sent 40
> > MB data as a reply to query.
> > May be based on your explaination, as GIOP call can return virtually
> > unlimited data, this reply may overflow JVM buffer which uses JacORB.
> > Is it correct?
> >
>
> I imagine you are probably hitting some capacity limit. Whether it is in
> the JVM, jacORB, or the host in general I can't say.
>
> However, GIOP needs to allocate enough space tho hold the entire message
> being received, so if you have a physical limitation of about 40 MB per
> message, perhaps you can structure this interface so that the troublesome
> messages, whether requests or replies, stay under the 40 MB limit. For
> example, if it is a huge buffer sent in a request, then you cold break it
> into a series of smaller chunks that you can process somehow. For large
> replies, you could return an iterator instead, so the client could request
> smaller sections.
>
> ultimately, thee is nothing special about 40 MB, so if that's where bad
> things happen in your Java code, I think that's where you need to focus
> your debugging effort.
>
> Best regards,
> Phil
>
> --
> Phil Mesnier
> Principal Engineer & Partner
>
> OCI | WE ARE SOFTWARE ENGINEERS.
> tel  +1.314.579.0066 x225
> ociweb.com
>
>
>
>
>
> _______________________________________________
> tao-users mailing list
> tao-users at list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/tao-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.isis.vanderbilt.edu/pipermail/tao-users/attachments/20160830/f38fa077/attachment.html>