Further to#113 theByteBufProxy has been intermittently failing with messages such asjava.lang.IndexOutOfBoundsException: readerIndex: 0, writerIndex: 4 (expected: 0 <= readerIndex <= writerIndex <= capacity(0)). The intermittent nature of this failure has made it a long-standing bug that was previously thought fixed, but I have since found it can be reliably reproduced by makingCursorParamTest iterate 1,000 times.

By way of backgroundByteBufProxy operates by usingUnsafe to set the "length" field ofPooledUnsafeDirectByteBuf. It is therefore dependent on all buffers being of that type, otherwise the address offset of the "length" field would be incorrect.

Further investigation revealed that occasionally aSimpleLeakAwareByteBuf was returned byPooledByteBufAllocator.DEFAULT. This subsequently caused the length to be incorrectly set in such instances and the bounds check to fail duringByteBufProxy.out(...) invocations.

Modifications have been made to specifically test the type of any created buffer in order to ensure it is aPooledUnsafeDirectByteBuf and fail after several retries without obtaining one. This should provide a reasonable approach given that buffers are cached and reused.

It is noted that user-provided buffers are not impacted by this requirement to usePooledUnsafeDirectByteBuf as their memory address and applicable slice range is obtained from standard Java accessors defined on theByteBuf type.