You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "paul cannon (JIRA)" <ji...@apache.org> on 2012/08/01 06:25:35 UTC

[jira] [Commented] (CASSANDRA-4473) Binary protocol: handle asynchronous execution (better)

    [ https://issues.apache.org/jira/browse/CASSANDRA-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426324#comment-13426324 ] 

paul cannon commented on CASSANDRA-4473:
----------------------------------------

This patch doesn't associate response streamIds with the corresponding request streamIds. Is that an oversight, or is that planned for a future change? Currently all response streamIds from the server will be 0.

And just a minor nit: 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.
                
> 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.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