René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"IndexOutOfBoundsException due to SimpleLeakAwareByteBuf","articleBody":"Further to #113 the `ByteBufProxy` has been intermittently failing with messages such as `java.lang.IndexOutOfBoundsException: readerIndex: 0, writerIndex: 4 (expected: 0 \u003c= readerIndex \u003c= writerIndex \u003c= 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.\r\n\r\nBy 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.\r\n\r\nFurther 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.\r\n\r\nModifications 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.\r\n\r\nIt 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.","author":{"url":"https://github.com/bp-alex","@type":"Person","name":"bp-alex"},"datePublished":"2019-06-01T04:38:02.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/133/lmdbjava/issues/133"}