[
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.
