• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Won't Fix
  • Communications Layer
  • cdennis
  • Reporter: cdennis
  • April 15, 2011
  • 0
  • Watchers: 1
  • July 27, 2012
  • May 12, 2011


It appears that a bug was introduced in to the sun.nio.ch.IOUtil class of JRockit (probably in R28.1). The buggy JRockit code attempts to call array() on a arbitrary heap ByteBuffer in order to access it’s contents and copy it across to a temporary direct ByteBuffer before writing the data to a SocketChannel. If the heap ByteBuffer is read-only then it will throw ReadOnlyBufferException when array() is called, as this would given unguarded write access to the buffers contents.

In pre 3.5 releases this trips up our NIO code (TCConnectionImpl) as we pass read-only heap buffers to SocketChannel.write(ByteBuffer), we can work around this by simply passing in a duplicate instead which will allow the write call. In normal 3.5 operation this doesn’t happen as the new message packing functionality copies the data into direct ByteBuffers before writing to the SocketChannel, it does however still happen if message packing is disabled. We should also check to make sure none of the other NIO code can trip over this bug.


Chris Dennis 2011-04-15

Issue “filed” in the JRockit forums here: http://forums.oracle.com/forums/thread.jspa?threadID=2208477&tstart=0

Fiona OShea 2011-04-19

Is this resolved in 3.5.1 or 3.5.0?

Chris Dennis 2011-04-19

It’s not technically resolved in either:

In 3.4.x: (and earlier) this will happen with default settings.

In 3.5.x: Manoj’s new comms mode means that in order to trigger the bug you need to disable message packup via the relevant TC property.

Chris Dennis 2011-04-22

This issue only affects 3.5+ in a very minor way - it’s highly unlikely that we will ever fix this in 3.5+ unless we find users regularly disabling message pack-up in these releases.

Since this is really a 3.4.x issue I have marked it as “Fix In Branch: 3.4” and moved it out to Ulloa_Holding.

Chris Dennis 2011-05-12

It appears Oracle have fixed the underlying issue:


Chris Dennis 2011-05-12

Oracle have fixed this bug in 28.1.3, and as far as we can tell it was only introduced in R28.1.0. Since the version range in which this bug occurs is so narrow, I’m going to go with the assumption that we can ask users to upgrade to R28.1.3 to fix this issue.