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 Tue, 03 Jul 2012 13:55:23 GMT


Sylvain Lebresne commented on CASSANDRA-2478:

bq. All of protocol related classes are placed under org.apache.cassandra.cql3.transport,
but I think it'd be better to keep them under org.apache.cassandra.transport.

Make sense.

bq. Native transport service starts by default along with thrift service, but isn't it better
to turn off by default to indicate "for developing client only"?

I agree. And in any case, most people won't want to run both server at the same time anyway,
so I've added flag for both thrift and the new native server in the config file to choose
whether to start those. You can still overwrite those by used startup flags, but I believe
most of the time the config setting will be more convenient. And the default is to not start
the native transport by default while it's still beta.

I've rebased the branch and added the two changes above in
I also made a small modification due to a remark made by Norman on github. Taking about that,
@Norman, was that your only remark or are you just not done looking at this?

bq. And not necessary at this time, but it is nice to have unit test like CliTest, based on
debug client.

Not sure what you mean by that.

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