cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2478) Custom CQL protocol/transport
Date Fri, 06 Jul 2012 14:30:35 GMT


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:
>             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:!default.jspa
For more information on JIRA, see:


View raw message