Did you tried to observe it using cassandra-cli? (the thrift client)
It shows the 'disk-layout' of the data and may help as well.

Otherwise, if you can reproduce it having a varint as the last part of the partition key (or at any other location), this may well be a bug.

Carlos Alonso | Software Engineer | @calonso

On 23 November 2015 at 18:48, Ramon Rockx <ramon@iqnomy.com> wrote:
Hello Carlos,

On Mon, Nov 23, 2015 at 3:31 PM, Carlos Alonso <info@mrcalonso.com> wrote:
Well, this makes me wonder how varints are compared in java vs python because the problem may be there.

I'd suggest getting the token, to know which server contains the missing data. Go there and convert sstables to json, find the record and see what's there as the tnt_id. You could also use the thrift client to list it and see how it looks on disk and see if there's something wrong.

If the data is there and looks fine, probably there's a problem managing varints somewhere in the read path.

Thanks for your input.
I converted the sstables to json and found the record, it starts with:

{"key": "00080000000e70451f640000040000000500","columns": [["cba56260-5c1c-11e3-bf53-402d20524153:1","{\"v\":1383400,\"s\":2052461,\"r\"...8<...

It's a composite key and I don't know how to deserialize it properly.
Maybe I can setup a test case to reproduce the problem.