cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: non blocking Cassandra with Tornado
Date Sat, 07 Aug 2010 00:53:11 GMT
See comments to https://issues.apache.org/jira/browse/CASSANDRA-1256

On Fri, Jul 30, 2010 at 12:57 AM, Ryan Daum <ryan@thimbleware.com> wrote:
> 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.
> R
>
> On Tue, Jul 27, 2010 at 11:51 AM, Dave Viner <daveviner@pobox.com> 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:
>> http://blog.rapleaf.com/dev/2010/06/23/fully-async-thrift-client-in-java/
>> 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
>> <peter.schuller@infidyne.com> 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
>>
>
>



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support
http://riptano.com

Mime
View raw message