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: Compiler (PHP)
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
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.
-
You can reply to this email to add a comment to the issue online.
