BufferOverflow exception on SocketChannel.read()

[ATC]

Folks,

I have a situation that I can't explain and maybe it is due to some
lack of understanding of NIO. I have allocated a non-direct
ByteBuffer and passed it as an argument to SocketChannel.read(). The
channel is blocking. I am (intermittantly) getting a
java.nio.BufferOverflowException and I don't understand how that is
possible. The partial stacktrace below shows where it occurs.

at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:190)
at sun.nio.ch.IOUtil.read(IOUtil.java:209)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:207)

I have access to the HeapByteBuffer.java file and can see that the
exception appears to be thrown because something in the sun.nio.ch
package is copying data from what appears to be an internal ByteBuffer
into what I'm assuming is my ByteBuffer. Since the internal
ByteBuffer has more data than my ByteBuffer can hold, the exception
gets thrown.

I don't have access to the sun.nio.ch source files, so I can't look at
them to see what is happening.

What I don't understand is why this is possible. I thought that if I
passed a ByteBuffer to SocketChannel.read(), it would only read as
much data into the ByteBuffer as the ByteBuffer could hold. Why is
this exception thrown? Is my understanding incorrect?

Thanks to anyone who can help me make sense of this.

ATC

 

[Vincent Cantin]

Folks,

I have a situation that I can't explain and maybe it is due to some
lack of understanding of NIO. I have allocated a non-direct
ByteBuffer and passed it as an argument to SocketChannel.read(). The
channel is blocking. I am (intermittantly) getting a
java.nio.BufferOverflowException and I don't understand how that is
possible. The partial stacktrace below shows where it occurs.

at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:190)
at sun.nio.ch.IOUtil.read(IOUtil.java:209)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:207)

I have access to the HeapByteBuffer.java file and can see that the
exception appears to be thrown because something in the sun.nio.ch
package is copying data from what appears to be an internal ByteBuffer
into what I'm assuming is my ByteBuffer. Since the internal
ByteBuffer has more data than my ByteBuffer can hold, the exception
gets thrown.

I don't have access to the sun.nio.ch source files, so I can't look at
them to see what is happening.

What I don't understand is why this is possible. I thought that if I
passed a ByteBuffer to SocketChannel.read(), it would only read as
much data into the ByteBuffer as the ByteBuffer could hold. Why is
this exception thrown? Is my understanding incorrect?

Thanks to anyone who can help me make sense of this.

ATC

I don't know exactly what is the problem, but ..
Do you remember to set the reading position of the buffer to the beginning
each time you read something ?

 

[ATC]

I don't know exactly what is the problem, but ..
Do you remember to set the reading position of the buffer to the
beginning each time you read something ?

Thanks for responding!

I'm checking on that now, but my point is that I don't think this is
necessary. Since the read call is only suppossed to read as much data
into the buffer as it has room for, if the buffer has no room, the read
call should just return 0. Am I mistaken here? The documentation is a
little terse in this area, so my assumption may be incorrect.

ATC

 

[Steve Horsley]

I'm checking on that now, but my point is that I don't think this is
necessary. Since the read call is only suppossed to read as much data
into the buffer as it has room for, if the buffer has no room, the read
call should just return 0. Am I mistaken here? The documentation is a
little terse in this area, so my assumption may be incorrect.

I have occasionally seen situations (not related to this thread) where
asking to read/write 0 bytes ended up trying to read/write a very large
number instead. It may be worth coding to not call read() if there's no
space left, or catch the exception and then print how much space you
_thought_ you had, just to see if it's the 0-bytes-space case that's
causing the problem.

Steve