lhotari commented on PR #4196: URL: https://github.com/apache/bookkeeper/pull/4196#issuecomment-1924562204
> as I understood, if you take offset (readerIndex) and length from the "wrapped" buffer, unwrapped.decompose(offset, len) will use these to provide proper buffers (slices if needed). I just briefly looked at the code of decompose, please double-check. @dlg99 won't work. You would need to know implementation details. If you check the implementations, there's also other internal state in wrappers that cannot be observed. The Netty 4 API is useless in many ways for decomposing buffers. This problem is resolved in Netty 5 API. The previous discussion has a link to the draft PR where I asked about this from Netty maintainers. The ByteBufVisitor solution in this PR is a result of many iterations. I actually tried the solution you are describing as one of the first attempts and ran into a dead-end. I'm confident that there isn't many other safe approaches for Netty 4, other than the getBytes/setBytes hack used in ByteBufVisitor. It's a safe hack. The stateless visitor minimises object allocations and that won't become a bottleneck. The other benefit of ByteBufVisitor is that it will be able to iterate through any buffer hierarchy. That will also improve performance, although it's not likely that there are many of these cases in the current hotpaths. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
