See comments to https://issues.apache.org/jira/browse/CASSANDRA-1256
On Fri, Jul 30, 2010 at 12:57 AM, Ryan Daum <r...@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 <davevi...@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.schul...@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
