You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Nate McCall (JIRA)" <ji...@apache.org> on 2010/07/29 10:01:17 UTC
[jira] Issue Comment Edited: (THRIFT-830) Switch binary field
implementation from byte[] to ByteBuffer
[ https://issues.apache.org/jira/browse/THRIFT-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893543#action_12893543 ]
Nate McCall edited comment on THRIFT-830 at 7/29/10 4:01 AM:
-------------------------------------------------------------
After some initial experimentation patching these changes into Cassandra I have found some strange behavior.
It appears the message is not being broken up correctly into component parts. When I examine the message to retrieve the key, it appears the whole message body is intact within the buffer. For example when I expect to receive "k1", the buffer contains the entire contents of a Cassandra insert:
[0, 0, 0, 6, 105, 110, 115, 101, 114, 116, 1, 0, 0, 0, 4, 11, 0, 1, 0, 0, 0, 2, 107, 48, 12, 0, 2, 11, 0, 3, 0, 0, 0, 8, 73, 110, 100, 101, 120, 101, 100, 49, 0, 12, 0, 3, 11, 0, 1, 0, 0, 0, 9, 98, 105, 114, 116, 104, 100, 97, 116, 101, 11, 0, 2, 0, 0, 0, 8, 49, 57, 55, 53, 49, 50, 51, 48, 12, 0, 3, 10, 0, 1, 0, 4, -116, -127, 83, 19, -95, -32, 0, 0, 8, 0, 4, 0, 0, 0, 1, 0]
Where previously, it was simply [107,49]
I will try to distill this into a reproducable test case of some sort, but hopefully the above can at least provide some information.
Edit: this is with TBinaryProtocol and TFramedTransport
was (Author: zznate):
After some initial experimentation patching these changes into Cassandra I have found some strange behavior.
It appears the message is not being broken up correctly into component parts. When I examine the message to retrieve the key, it appears the whole message body is intact within the buffer. For example when I expect to receive "k1", the buffer contains the entire contents of a Cassandra insert:
[0, 0, 0, 6, 105, 110, 115, 101, 114, 116, 1, 0, 0, 0, 4, 11, 0, 1, 0, 0, 0, 2, 107, 48, 12, 0, 2, 11, 0, 3, 0, 0, 0, 8, 73, 110, 100, 101, 120, 101, 100, 49, 0, 12, 0, 3, 11, 0, 1, 0, 0, 0, 9, 98, 105, 114, 116, 104, 100, 97, 116, 101, 11, 0, 2, 0, 0, 0, 8, 49, 57, 55, 53, 49, 50, 51, 48, 12, 0, 3, 10, 0, 1, 0, 4, -116, -127, 83, 19, -95, -32, 0, 0, 8, 0, 4, 0, 0, 0, 1, 0]
Where previously, it was simply [107,49]
I will try to distill this into a reproducable test case of some sort, but hopefully the above can at least provide some information.
> Switch binary field implementation from byte[] to ByteBuffer
> ------------------------------------------------------------
>
> Key: THRIFT-830
> URL: https://issues.apache.org/jira/browse/THRIFT-830
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (Java), Library (Java)
> Reporter: Bryan Duxbury
> Assignee: Bryan Duxbury
> Fix For: 0.4
>
> Attachments: thrift-830.patch
>
>
> Instead of using byte[] as the implementation for binary fields, let's use ByteBuffer.
> There's nothing that you can do with byte[] that you can't also do with ByteBuffer, and there are more things you can do with ByteBuffer. It opens the way for us to avoid needless buffer copies on serialization and deserialization. It gives us a generally accepted equals() and compareTo() implementation, so we don't have to have custom cases for that anymore.
> Making this change will probably cause more than a little bit of trauma, changing the method signatures in both TProtocol and generated code. It's _possible_ that I could be persuaded to support a command line switch for producing old-style byte[] methods in some contexts, but I'd love not to waste time supporting suboptimal features.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.