cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holger Hoffstätte (JIRA) <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-2478) Custom CQL protocol/transport
Date Fri, 06 Jul 2012 14:09:34 GMT

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

Holger Hoffstätte commented on CASSANDRA-2478:
----------------------------------------------

Hi - just found this and got curious (esp. after our conclusions on Thrift in Cologne :).
The protocol looks straightforward enough, though I'm not sure about the general assumption
of synchronous behaviour. My understanding so far is that this is a completely synchronous
request/response protocol with no provision for out-of-order or async-oneway commands (which
might also obviate otherwise empty Void RESULTs), and I don't see frame or command/reply correlation
numbers anywhere. These might become necessary for incremental server-push as well. Is this
assessment correct? Is this omission intentional? Just asking whether this was a consideration
at all since it has coupling implications for the actual transport layer and client interaction.

                
> Custom CQL protocol/transport
> -----------------------------
>
>                 Key: CASSANDRA-2478
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2478
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Core
>            Reporter: Eric Evans
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>              Labels: cql
>             Fix For: 1.2
>
>         Attachments: cql_binary_protocol, cql_binary_protocol-v2
>
>
> A custom wire protocol would give us the flexibility to optimize for our specific use-cases,
and eliminate a troublesome dependency (I'm referring to Thrift, but none of the others would
be significantly better).  Additionally, RPC is bad fit here, and we'd do better to move in
the direction of something that natively supports streaming.
> I don't think this is as daunting as it might seem initially.  Utilizing an existing
server framework like Netty, combined with some copy-and-paste of bits from other FLOSS projects
would probably get us 80% of the way there.

--
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