Pandra sometimes not adding #33

Closed
houseoftequila opened this Issue May 10, 2010 · 10 comments

Comments

Projects
None yet
2 participants

Assuming $email = 'test@test.com

        $this->scf->setKeyID($email);
        $info = new PandraSuperColumn('info');
        $info->addColumn('password', 'string');
        $info->addColumn('name', 'string');
        $info->addColumn('userlevel', 'string');
        $info->setColumn('password', md5($password));
        $info->setColumn('name', $name);
        $info->setColumn('userlevel',$userlevel);
        $this->scf->addSuper($info);
        if(!$this->scf->save()){
            die;
        }

If i run this code, then delete the records in the cassandra CLI

        cassandra> del Keyspace.Users['test@test.com']

Then try and re-run the above php code it will not run..> I am however able to add via the Cassandra cli at that point.

Owner

mjpearson commented May 11, 2010

Thanks, can you try dumping the output of $this->scf->errors; and pasting. eg:

if(!$this->scf->save()){
var_dump($this->scf->errors); }

Also, internal errors can be sent to syslog via the logger module, just need to enable it and tail the log :

PandraCore::addLogger('Syslog');

... should give you a good idea of what's going on if no exceptions are being generated. Failing that could you also paste your super column family init(); or construction method.

-michael

The var_dump will not output anything as the save comes back without errors (the die never gets hit) It also seems that yesterday, the keys i were not able to add, I'm now able to add, but only once as the second time It fails. Could this be related to https://issues.apache.org/jira/browse/THRIFT-729 ?

Owner

mjpearson commented May 12, 2010

It does sound like an issue with tombstoned columns - they would have become available for writing after flush/compaction. It only affects 32-bit systems trying to use the thrift_protocol module. if you're using this kind of setup, you'll need to disable the thirft_protocol module so pandra can roll back to microtimes via TBinaryProtocol.

Owner

mjpearson commented May 12, 2010

found the underlying issue (was in pandra) cassandra-cli is using a 64-bit long, but getTime helper only returning microtime. Now detects the length of the integer and multiplies accordingly. Should be now fixed in the latest commit - I'm guessing you're on 64-bit arch?

Yes... Currently running on Snow Leopard... We'll test things tomorrow and get back to you. Thanks a ton!

This appears to still not work... I am using the code from the svn mirror revision 133. From digging into things more, The build of PHP i have is actually 32 bit, and its using the following to calculate time: "return round(microtime(true) * 1000, 3);"

Could this be an issue with the fact that one client (cli) is using 64 bit times and the other client (php) is using 32bit?

I also tested with using the thrift_protocol.so module so getTime uses the call to time() instead of the rounded microtime. This also fails.

Owner

mjpearson commented May 12, 2010

Can you try the latest head, minor patch to use microtime in most cases. I can't really suggest using thrift_protocol.so on 32 bit systems, there's a host of issues with the way it casts int64's

I disabled thrift_protocol.so, and updated to the latest... everything seems to be fixed. thanks.

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment