cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Hack <>
Subject A few questions about Cassandra's native protocol
Date Wed, 22 Aug 2012 22:53:22 GMT

I am currently developing a client for Cassandra's new native protocol
in Go. Everything is working fine so far and I am quite happy with the
new protocol. Good work! Here a just a couple of questions and notes:

1) The native_protocol.spec should probably mention that it is based
on TCP. I greped the whole document for "UDP" and "TCP" and found

2) Streaming

I'm currently allocating and reading one frame after another on the
client side. The thing that worries me - If I have understood the
current specification correctly - is that all rows are returned in a
single frame. If the database is quite large, this frames might not
fit into the memory.

I was thinking about using buffered I/O instead, but that's probably
not a good solution either, because then a single thread that iterates
over the rows slowly will block the whole connection. In my opinion it
would be a good idea to split the response to a couple of frames, so
that other threads (with different stream ids) are still able to use
the connection concurrently and push notifications are still
delivered. A "last" flag might indicate the end of the response.

3) Stability

During the development of the client, I happened to send some invalid
requests to the server. In particular, I have send a startup message
with a body length of 0 (and no body afterwards). In those cases,
Cassandra immediately started to use all of my 8GBs of RAM and spawned
up to 1000 threads. The log files were full of "out of memory" and
"couldn't spawn process" messages and it was quite difficult to kill
Cassandra again.

4. Prepared Statements

It should be possible to prepare statements that do not take any
arguments. This simplifies the client development significantly
(otherwise everybody has to write his own parser to determine the
number of arguments) and might also speed up common queries.
The current implementation returns a "java.lang.AssertionError" error
response in that case.


View raw message