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.
Aaron
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.
Aaron
On 28 Jul, 2010,at 03: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:Or, even better, port the Thrift async client to work for python and other languages.Dave VinerOn 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(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
