[jira] Commented: (THRIFT-788) thrift_protocol.so: multiget/multiget_slice does not handle more than 17 keys correctly

["Arya Goudarzi (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879541#action_12879541 ] 

Arya Goudarzi commented on THRIFT-788:
--------------------------------------

Refining my notes bellow according to the comment of original creator of this issue:

Mine is happening to SuperColumnFamily with 9 or more column per row.


Moving discoveries from CASSANDRA-1199 to here:

I am comparing the following

    * Reading of 100 SuperColumns in 1 SCF row using multiget_slice() with 1 key and 1 column name in 100 loop iterations
    * Reading of 100 SuperColumns in 1 SCF row using multiget_slice() with 1 key and 100 column names in a single call

I always get a consistent result and that is the single call takes more time then 100 calls. After some investigation, it seamed that the time it took to execute multiget_slice with 100 columns is always close to the TSocket->recvTimeout, Increasing the recvTimeout results that call to take that much time before retuning. After digged into TSocket->read (TSocket.php line 261) and looking at some of the meta data of fread, it seams that none of the buffer chunks get the eof flag=1. And the stream waits till timeout has reached.

This only happens if TBinaryProtocolAccelerated (thrift_protocol.so) is used.

I have attached my code to reproduce this issue. You can set the timeouts to see how it affects the read call in multiget_slice.

Please investigate.

This a timing example for the above scenario with TSocket's default timeouts:

100 Sequential Writes took: 0.4047749042511 seconds;
100 Sequential Reads took: 0.16357207298279 seconds;
100 Batch Read took: 0.77017998695374 seconds;






> 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: Library (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.