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

Sylvain Lebresne commented on CASSANDRA-2478:
---------------------------------------------

I did consider a fully asynchronous protocol for a minute, but I felt that it 
would complicate things quite a bit and I'm unsure of the benefits. That is, I 
can see the point for out-of-order frame in things like SPDY where you want to 
multiplex lots of different streams inside the same connection, but it feels 
overkill for us. I typically don't think having clients maintaining a pool of 
connections be a big problem, and in fact client will want that anyway because 
you want to load balance the connections over multiple nodes.

That being said, there is nothing in the spec (or it's unintentional) 
preventing one way commands nor even incremental server-push. There is no frame 
sequence, which prevent completely out-of-order frames, but that doesn't mean 
client shouldn't say expect that the next frame after a query request must 
necessarily be a result frame. For instance, I intend to explore adding some 
form of server event push, where the server could push (at any time) a event 
frame saying for instance that a new node joined the cluster.
                
> 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

        

Reply via email to