SuperColumn is not saved after a delete

[mikeytag]

I seem to have come across a bug with SuperColumns. I can add one successfully (i.e. add through Pandra and then go to the CLI and type get ks.cf['key']) However, if I delete the key by running "del ks.cf['key']" and then add that same column back through Pandra a subsequent get ks.cf['key'] always returns 0 results.

It seems that Pandra should add the SuperColumn back with that key, but maybe is getting tripped up because the row was "tombstoned"? FWIW, I can do a "set ks.cf['key']['super']['col'] = 'val'" from the CLI and the row shows up.

Michael, I have been digging through the lib folder to see if I can track the problem down, but I am still getting my bearings and haven't been able to find the culprit yet.

[mikeytag]

On another note: File: lib/Core.class.php Line 444 $mutation = Array(); should be $mutations = Array();

[mikeytag]

sorry, I capitalized it. I really meant:

        $mutations = array();

;)

[mjpearson]

Thanks Mike I'll check it out. It sounds like a timestamp issue, are you able to confirm whether the php module is being used, and whether your system is 32 or 64 bit?

[mikeytag]

Ok, further testing shows that the issue only shows up on a 32 bit instance. The 64 bit client inserts the data as expected. I am guessing there is something strange going on with the 32 bit thrift install. I double checked my ntp settings, and all servers were on the exact same time so I don't believe the internal clock is to blame.

When I installed on the 32 bit machine, I followed the instructions you gave for compiling the thrift_protocol.so. Was I supposed to do that for a 64 bit install only? I figured the 32 bit machine would handle it just the same, and it does seem to run properly (other than this bug I came across).

[mikeytag]

FWIW, I commented out /etc/php5/conf.d/thrift_protocol.ini and the problem persisted on a 32 bit client.

[mjpearson]

Hey Mike, I've made a quick patch to core to get this working on 32 bit systems (current HEAD), there's a thrift module bug on 32-bit systems, so maybe keep that turned off for the meantime until a fix is organised. The problem is the CLI properly uses i64 microtimes, but the thrift module doesn't seem to, so the changes are writing as 10 digit times, which are always superseded by the 13 digit microtimes in the cli. Fun!

[mjpearson]

logged on Thrift Jira https://issues.apache.org/jira/browse/THRIFT-729

[mikeytag]

Don't you love bugs like that? So much fun! Thanks for looking into it, and I'll keep track of the Apache ticket. For now, I may just have to upgrade my last few 32 bit machines to 64.