Add support for CQL Binary Protocol about fluentcassandra HOT 4 OPEN

Just wondering if anyone working on this? DataStax implemented this feature in its driver. This binary protocol seems to offer x2-3 performance increase for the batch inserts in our application.

from fluentcassandra.

Nobody right now. Do you want to take it?

Nick Berardi
(484) 302-0125
Sent on the go from my phone.

On Jul 26, 2013, at 7:11 AM, Oleksii Mandrychenko [email protected]
wrote:

Just wondering if anyone working on this? DataStax implemented this feature
in its driver. This binary protocol seems to offer x2-3 performance
increase for the batch inserts in our application.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/59#issuecomment-21614636
.

from fluentcassandra.

I would like to do minor contribution, such as writing tests and implementing tiny little features. So if someone knows the details of the protocol and have vision to do it, I would like to assist.

Probably cannot do more due to other commitments and lack of knowledge.

from fluentcassandra.

I've given this issue some thought as of late... Eventually we're going to have to add support for the native protocol when DataStax starts introducing features that depend on it.

As I understand it, the network protocol itself is just protobuffs with framed messages. DataStax implemented this themselves in their CQL3 driver as did CqlSharp (https://github.com/reuzel/CqlSharp) - we could follow suit or add a dependency for a protobuff implementation like https://code.google.com/p/protobuf-net/ and add the framing rules on top of it.

The more complicated part, IMHO, is backwards compatibility with existing Thrift-only clients. Would we maintain separate native protocol connection pools? Require a given CassandraContext to be native-only or Thrift-only? Mix-and-match?

I don't really have a good answer to the latter, but if I had to make a decision right now I would go with the "network type" as something that has to be specified during configuration of a CassandraContext.

It can't be changed after the context is created and maintains separate connection pools for Thrift vs. Native if someone is using both types of connections inside a single AppDomain, which is what you'd expect to see in the case of a legacy FluentCassandra user who's gradually migrating over to CQL3.

Thoughts?

from fluentcassandra.