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 <https://twitter.com/calonso> On 23 November 2015 at 18:48, Ramon Rockx <[email protected]> wrote: > Hello Carlos, > > On Mon, Nov 23, 2015 at 3:31 PM, Carlos Alonso <[email protected]> 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. > > Thanks, > Ramon >
