[Spread-users] Re: NegativeArraySizeException under load

Jonathan Stanton jonathan at cnds.jhu.edu
Fri Apr 1 09:28:46 EST 2005


Hello,

This is quite odd as the socket buffer size should NEVER cause TCP 
streams to become corrupted. In theory you could have a socket buffer of 
10 bytes and TCP would correctly (but very very slowly) deliver your 
data. 

I think there must be another bug that causes the corruption, but it is 
masked by the larger buffer sizes. I've seen stuff like this before so 
I'll look into it and see if I can figure out why. 

The reason the socket buffer setting code was commented out was that the 
calls did not work in Java 1.1 only in newer Java releases and at the 
time we wanted to support Java 1.1 JVMs. Java 1.1 is now pretty old so 
maybe it's time to drop support for it.

Cheers,

Jonathan

On Fri, Mar 18, 2005 at 09:27:37AM -0500, toby cabot wrote:
> toby cabot wrote:
> >We're seeing problems with the Java driver when we send a reasonable
> >(greater than a couple hundred messages per second) load of messages
> >across Spread.  <snip>
> >java.lang.NegativeArraySizeException
> (also OutOfMemoryExceptions)
> 
> One of my TCP-savvy colleagues chased down a workaround for this 
> problem.  The problems is caused by overruns in the TCP receive buffer, 
> so a workaround is to increase the receive buffer size.  In our case 
> 128k seems to work, but higher loads might require larger buffer sizes. 
>  Interestingly, there's a method called setBufferSizes() that has code 
> to increase the buffer size, but for some reason that code is commented out.
> 
> >// Set the send and receive buffer sizes.
> >/////////////////////////////////////////
> >private void setBufferSizes() throws SpreadException
> >{
> >/* NOT SUPPORTED IN 1.1			
> >	try
> >	{
> <snip>
> >	catch(SocketException e)
> >	{
> >		throw new SpreadException("set/getSend/ReceiveBufferSize(): 
> >		" + e);
> >	}
> >NOT SUPPORTED IN 1.1	*/
> >}
> 
> I'm not sure why it's commented out (maybe it's got other side effects) 
> but something like it should be put back as the driver can't cope with 
> non-trivial loads without it.
> 
> Any thoughts on the idea of adding some framing to the server-client 
> messages so that the driver can tell when an overrun has happened and 
> recover from it?
> 
> Thanks,
> Toby
> 
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users

-- 
-------------------------------------------------------
Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    
-------------------------------------------------------




More information about the Spread-users mailing list