[omniORB] COMM_FAILURE for "long" sequences

[Mårten Björkman]

Thank you Duncan! I moved the allocation of memory to the constructor of 
the server and then
it worked. However, if I do like this

void SeqTestServ::GetData(SeqTest::Data_out img, long int &size)
{
  unsigned char *dat = new unsigned char[totsize];
  img = new SeqTest::Data(totsize, totsize, dat, false);
  size = totsize;
  delete [] dat;
}

it does not work, if totsize is larger than about 128K. I suppose one 
way of solving it in my image
case would be to allocate memory using

img = new SegTest::Data(totsize);

and then let my image work on that memory before sending it away. Do you 
have suggestion? I
do not particularly like to allocate data in the constructor. If that is 
the problem than it is surprising
that the same piece of code has worked for two years with smaller images. :)

Thank you,

Mårten

Duncan Grisby wrote:

>On Tuesday 22 March, =?ISO-8859-1?Q?M=E5rten_Bj=F6rkman?= wrote:
>
>  
>
>>Thank you for you remark. Unfortunately, it's not due to improperly
>>set giopMaxMsgSize, which I believe is set to about 2M by
>>default. Then I would have got an exception earlier and never reach
>>socket sent(). It seems that the limit is about 128K. I tested a
>>minimal client-server thingie on another (single processor) Linux
>>machine running kernel version 2.4.20 and unfortunately got the same
>>error.  If this were a Linux error, many others would have seen the
>>same thing, I suppose. What makes an omniORB based application
>>different are the multiple threads. Somehow the ORB thread can not
>>read data stored by the server thread, if the sequence to be sent is
>>longer than 128K.
>>    
>>
>
>There is no "ORB thread". If you allocate your buffer in an up-call, it
>is the same thread that tries to do the send as was used for the
>up-call.
>
>Are you sure you're not accidentally releasing the image buffer before
>you return from the operation?  I don't know how your Image class works,
>but it looks to me like there's a good chance it's releasing the memory
>before you return. What happens if you run your code in valgrind?
>
>If you're definitely not releasing the memory prematurely, try editing
>the send function in src/lib/omniORB/orbcore/tcp/tcpConnection.cc. Right
>at the start of the function, there's an #ifdef for VMS that limits the
>send size to 64K. Try enabling that.
>
>Cheers,
>
>Duncan.
>
>  
>