[ 
https://issues.apache.org/jira/browse/CASSANDRA-9865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14644763#comment-14644763
 ] 

Ariel Weisberg edited comment on CASSANDRA-9865 at 7/28/15 5:59 PM:
--------------------------------------------------------------------

Yes it's still a problem. I think the issue is ByteOrder related. The vint code 
we have doesn't check to see if the byte order of the buffer is big endian.

We could
* assert the buffer is in the right order
* Throw a runtime exception if the order is wrong
* change the order of the buffer on enter/exit for vint read/write
* Do the byte swapping ourselves depending on the order of the buffer



was (Author: aweisberg):
Yes it's still a problem. I think the issue is ByteOrder related. The vint code 
we have doesn't check to see if the byte order of the buffer is big endian.

We could
* assert the buffer is in the right order
* Throw a runtime exception if the order is wrong
* change the order of the buffer on enter/exit for vint read/write
* Do the byte swapping ourselves depending on the order of the buffer (this has 
risk of using the order inconsistently)


> Broken vint encoding, at least when interacting with OHCProvider
> ----------------------------------------------------------------
>
>                 Key: CASSANDRA-9865
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9865
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>            Assignee: Ariel Weisberg
>             Fix For: 3.0 alpha 1
>
>         Attachments: 9865-hacky-test.txt
>
>
> I haven't investigated this very closely so I only have a slightly hacky way 
> to show the problem, but if you apply the patch attached, you'll see that the 
> vints serialized and the one deserialized are not the same ones. If you 
> remove the use of vints (as is currently on trunk, but only due to this issue 
> because we do want to use vints), everything works correctly.
> I'm honestly not sure where the problem is, but it sounds like it could be 
> either in {{NIODataInputStream}} or in the {{OHCProvider}} since it's used on 
> that test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to