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 Mon, 30 Jul 2012 18:39: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.txt

Attaching patch to do this (with an update to the protocol spec). This limit the number of
simultaneous streams to 128 which it seems to me should be enough and has the advantage of
fitting into the current 8 bytes frame header. If that is really deemed too low, we'll probably
have to bump the head to 12 bytes.

                
> 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

        

Mime
View raw message