You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by aaron morton <aa...@thelastpickle.com> on 2010/08/05 12:56:35 UTC

Re: non blocking Cassandra with Tornado

Have you had a chance to try this technique out in Java ?

I've not been able to get back to my original experiments for the last week. 

If it works you should be able to put together a non blocking client that still used thrift. 

Aaron
On 30 Jul 2010, at 16:57, Ryan Daum 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 <da...@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 <pe...@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
> 
>