[
https://issues.apache.org/jira/browse/THRIFT-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035589#comment-13035589
]
Nathaniel Cook commented on THRIFT-1058:
----------------------------------------
I stumbled across this because of the TFramedTransport. I wasn't using it for
any of my services but then to support an HsHa server I started to wrap my
normal socket transport in a framed one. Then it took a while but eventually I
discovered that because of the framed transport the ByteBuffers I was getting
had specific position and limit values set. So performing operations on the
ByteBuffers caused several problems. Mostly that the buffers weren't reusable
because I wasn't always reseting the position and limit. This inconsistent
behavior could easily be solved by slicing the ByteBuffers and would make
dealing them much easier.
> All ByteBuffers the client uses should be slice()ed
> ---------------------------------------------------
>
> Key: THRIFT-1058
> URL: https://issues.apache.org/jira/browse/THRIFT-1058
> Project: Thrift
> Issue Type: Bug
> Affects Versions: 0.6
> Reporter: ryan rawson
> Attachments: ByteBufferTest.java
>
>
> Right now the code does something like yay so:
> return ByteBuffer.wrap(array, pos, len);
> The only problem is that .wrap(byte[],int,int) returns a ByteBuffer with
> position equal to pos and limit set to pos+len. Which means users cant used
> 'rewind' or position(0).
> It would be cleaner if the contract was "ByteBuffers will have position=0,
> limit=how much data you have".
> The way to accomplish this would be to:
> return ByteBuffer.wrap(array, pos, len).slice();
> In exchange for 1 extra object alloc (which the GC can clean up quick) we get
> the benefit of a easier to use BB interface.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
