Further to #113 the ByteBufProxy has been intermittently failing with messages such as java.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 making CursorParamTest iterate 1,000 times.

By way of background ByteBufProxy operates by using Unsafe to set the "length" field of PooledUnsafeDirectByteBuf. 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 a SimpleLeakAwareByteBuf was returned by PooledByteBufAllocator.DEFAULT. This subsequently caused the length to be incorrectly set in such instances and the bounds check to fail during ByteBufProxy.out(...) invocations.

Modifications have been made to specifically test the type of any created buffer in order to ensure it is a PooledUnsafeDirectByteBuf 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 use PooledUnsafeDirectByteBuf as their memory address and applicable slice range is obtained from standard Java accessors defined on the ByteBuf type.