cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Morton <>
Subject Re: non blocking Cassandra with Tornado
Date Wed, 28 Jul 2010 03:55:55 GMT
Thanks for the link.

It is more of a thrift thing, perhaps I need to do some tests where the web handler sends
the get_slice to cassandra but never calls recv to see what could happen.

I'll take a look at the Java binding and see what it would take to offer a patch to Thrift.
Most people coding Python (including the guy sitting next to me) would probably so to use
the thrift Twisted binding.

May also take a look at the avro bindings.


On 28 Jul, 2010,at 03: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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
    • Unnamed multipart/related (inline, None, 0 bytes)
View raw message