cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Daum <>
Subject Re: non blocking Cassandra with Tornado
Date Fri, 30 Jul 2010 04:57:47 GMT
An asynchronous thrift client in Java would be something that we could
really use; I'm trying to get a sense of whether this async client is usable
with Cassandra at this point -- given that Cassandra typically bundles a
specific older Thrift version, would the technique described here work at
all with a 0.6.x or 0.7 distribution? Has anybody tried this?

Barring this we (place where I work, Chango) will probably eventually fork
Cassandra to have a RESTful interface and use the Jetty async HTTP client to
connect to it. It's just ridiculous for us to have threads and associated
resources tied up on I/O-blocked operations.


On Tue, Jul 27, 2010 at 11:51 AM, Dave Viner <> wrote:

> FWIW - I think this is actually more of a question about Thrift than about
> Cassandra.  If I understand you correctly, you're looking for a async
> client.  Cassandra "lives" on the other side of the thrift service.  So, you
> need a client that can speak Thrift asynchronously.
> You might check out the new async Thrift client in Java for inspiration:
> Or, even better, port the Thrift async client to work for python and other
> languages.
> Dave Viner
> On Tue, Jul 27, 2010 at 8:44 AM, Peter Schuller <
>> wrote:
>> > The idea is rather than calling a cassandra client function like
>> > get_slice(), call the send_get_slice() then have a non blocking wait on
>> the
>> > socket thrift is using, then call recv_get_slice().
>> (disclaimer: I've never used tornado)
>> Without looking at the generated thrift code, this sounds dangerous.
>> What happens if send_get_slice() blocks? What happens if
>> recv_get_slice() has to block because you didn't happen to receive the
>> response in one packet?
>> Normally you're either doing blocking code or callback oriented
>> reactive code. It sounds like you're trying to use blocking calls in a
>> non-blocking context under the assumption that readable data on the
>> socket means the entire response is readable, and that the socket
>> being writable means that the entire request can be written without
>> blocking. This might seems to work and you may not block, or block
>> only briefly. Until, for example, a TCP connection stalls and your
>> entire event loop hangs due to a blocking read.
>> Apologies if I'm misunderstanding what you're trying to do.
>> --
>> / Peter Schuller

View raw message