[ https://issues.apache.org/jira/browse/THRIFT-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nicholas Telford resolved THRIFT-788. ------------------------------------- Resolution: Duplicate Fix Version/s: 0.7 This sounds like a duplicate of #638 which has been fixed. If you still experience this issue post Thrift 0.7, please re-open with more information. > thrift_protocol.so: multiget/multiget_slice does not handle more than 17 keys > correctly > --------------------------------------------------------------------------------------- > > Key: THRIFT-788 > URL: https://issues.apache.org/jira/browse/THRIFT-788 > Project: Thrift > Issue Type: Bug > Components: PHP - Library > Environment: - ubuntu 10.04 32bit > - thrift svn > - php-5.3.2 with thrift_protocol.so 1.0 enabled > - cassandra 0.6+0.7/trunk > Reporter: Alexander Liemen > Labels: multiget, multiget_slice, php, thrift_protocol > Fix For: 0.7 > > Attachments: multiget_slice.php > > > thrift_protocol.so does not handle multiget/multiget_slice with more than 17 > keys correctly. The query time sky rockets from 10ms to a steady 900ms > starting with 18 keys. It doesn't matter if you fetch 18 or 50. Solid 900ms... > The bug can easily + steadily be reproduced: > - standard Keyspace1 / CF Standard1 setup > - name: Keyspace1 > replica_placement_strategy: > org.apache.cassandra.locator.RackUnawareStrategy > replication_factor: 1 > column_families: > - name: Standard1 > compare_with: BytesType > - insert e.g. 1000 columns email:value / testmail1-testmail1000 with key = > 1...1000 > - $keys=array('1','2',.....'17') > - $client->multiget_slice($keys,$columnParent,$predicate,$consistency_level); > -> 10ms > - $keys=array('1','2',.....'18') > - $client->multiget_slice($keys,$columnParent,$predicate,$consistency_level); > -> 900ms > > - $keys=array('1','2',.....'100') > - $client->multiget_slice($keys,$columnParent,$predicate,$consistency_level); > -> 900ms > It does return the right columns though. > It can easily be fixed: disable thrift_protocol.so ;) > This might be a 32bit microseconds issue. Still very strange though. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira