cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-4473) Binary protocol: handle asynchronous execution (better)
Date Wed, 01 Aug 2012 06:50:35 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sylvain Lebresne updated CASSANDRA-4473:
----------------------------------------

    Attachment: 4473-2.txt

bq. This patch doesn't associate response streamIds with the corresponding request streamIds

Oops, that's totally an oversight. Fixed in the attached v2.

bq. section 2.4 of the native_protocol.spec still describes 'opcode' as being 2 bytes, and
gives the possible opcode values as 16-bit hex.

Fixed too.

                
> Binary protocol: handle asynchronous execution (better) 
> --------------------------------------------------------
>
>                 Key: CASSANDRA-4473
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4473
>             Project: Cassandra
>          Issue Type: Improvement
>    Affects Versions: 1.2
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 1.2
>
>         Attachments: 4473-2.txt, 4473.txt
>
>
> The current implementation of the binary protocol handle message asynchronously. I.e.
if a client send multiple requests simultaneously, we will handle all request in parallel
and in particular we make no guarantee on the order with which the response are sent. But
then the client has no way to associate which response correspond to which query. This ticket
proposes adding a stream id to each frame. This id would be set to by the client, and the
server would just reuse the same id in the response. That way, the client can send multiple
simultaneous queries with different stream id and know which response correspond to which
request.
> This has the advantages of 1) being trivial to implement and 2) leaving the possibility
for synchronous clients (that wait for responses before sending a new request) to ignore that
stream id and just use 0 all the time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message