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.
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.
On Tue, Jul 27, 2010 at 11:51 AM, Dave Viner <firstname.lastname@example.org>
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.
On Tue, Jul 27, 2010 at 8:44 AM, Peter Schuller <email@example.com>
> The idea is rather than calling a cassandra client function like(disclaimer: I've never used tornado)
> get_slice(), call the send_get_slice() then have a non blocking wait on the
> socket thrift is using, then call recv_get_slice().
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