Re: read one -- internal behavior
Note that article pretty much covers it all; the nice thing about rapid-read protection is that the dynamic snitch works on a per node statistics level to pick which node(s) (in this case one), so a single poorly performing table (perhaps corrupted SSTables on that node causing no responses and timeouts) can have no significant effect on the dynamic snitch, but the rapid-read protection can cause a much more proactive speculative read to another node that will satisfy the request long before the other node times out (though frankly in practice we keep timeouts pretty low, since we have multiple levels of fallback retry and would much rather do that quickly than wait and hope). On Mar 7, 2014, at 8:12 PM, Michael Shuler mich...@pbandjelly.org wrote: Actually, this is tunable in = 2.0.2 ;) http://www.datastax.com/dev/blog/rapid-read-protection-in-cassandra-2-0-2 Michael On 03/07/2014 07:33 PM, Jonathan Lacefield wrote: Yikes my apologies. B is not the answer On Mar 7, 2014, at 8:24 PM, Russell Hatch rha...@datastax.com mailto:rha...@datastax.com wrote: If you are using cqlsh, you can get a look at what's happening behind the scenes by enabling tracing with 'tracing on;' before executing a query. In this scenario you'll see 'Sending message to [ip address]' for each of the replicas. On Fri, Mar 7, 2014 at 5:44 PM, Jonathan Lacefield jlacefi...@datastax.com mailto:jlacefi...@datastax.com wrote: B is the answer On Mar 7, 2014, at 7:35 PM, James Lyons james.ly...@gmail.com mailto:james.ly...@gmail.com wrote: I'm wondering about the following scenario. Consider a cluster of nodes with replication say 3. When performing a read at read one consistency and lets say my client isn't smart enough to route the request to the Cassandra node housing the data at first. the contacted node acts as a coordinator and forwards the request to: A) a node that houses the data and waits for a reply, possibly timesout and re-issues to another in a failure or slow host scenario. or B) all (3) the nodes that house the data and returns after any one of them replies. I'm hoping for B... anyone know for sure? smime.p7s Description: S/MIME cryptographic signature
Re: read one -- internal behavior
If you are using cqlsh, you can get a look at what's happening behind the scenes by enabling tracing with 'tracing on;' before executing a query. In this scenario you'll see 'Sending message to [ip address]' for each of the replicas. On Fri, Mar 7, 2014 at 5:44 PM, Jonathan Lacefield jlacefi...@datastax.comwrote: B is the answer On Mar 7, 2014, at 7:35 PM, James Lyons james.ly...@gmail.com wrote: I'm wondering about the following scenario. Consider a cluster of nodes with replication say 3. When performing a read at read one consistency and lets say my client isn't smart enough to route the request to the Cassandra node housing the data at first. the contacted node acts as a coordinator and forwards the request to: A) a node that houses the data and waits for a reply, possibly timesout and re-issues to another in a failure or slow host scenario. or B) all (3) the nodes that house the data and returns after any one of them replies. I'm hoping for B... anyone know for sure?
Re: read one -- internal behavior
Yikes my apologies. B is not the answer On Mar 7, 2014, at 8:24 PM, Russell Hatch rha...@datastax.com wrote: If you are using cqlsh, you can get a look at what's happening behind the scenes by enabling tracing with 'tracing on;' before executing a query. In this scenario you'll see 'Sending message to [ip address]' for each of the replicas. On Fri, Mar 7, 2014 at 5:44 PM, Jonathan Lacefield jlacefi...@datastax.comwrote: B is the answer On Mar 7, 2014, at 7:35 PM, James Lyons james.ly...@gmail.com wrote: I'm wondering about the following scenario. Consider a cluster of nodes with replication say 3. When performing a read at read one consistency and lets say my client isn't smart enough to route the request to the Cassandra node housing the data at first. the contacted node acts as a coordinator and forwards the request to: A) a node that houses the data and waits for a reply, possibly timesout and re-issues to another in a failure or slow host scenario. or B) all (3) the nodes that house the data and returns after any one of them replies. I'm hoping for B... anyone know for sure?
Re: read one -- internal behavior
Actually, this is tunable in = 2.0.2 ;) http://www.datastax.com/dev/blog/rapid-read-protection-in-cassandra-2-0-2 Michael On 03/07/2014 07:33 PM, Jonathan Lacefield wrote: Yikes my apologies. B is not the answer On Mar 7, 2014, at 8:24 PM, Russell Hatch rha...@datastax.com mailto:rha...@datastax.com wrote: If you are using cqlsh, you can get a look at what's happening behind the scenes by enabling tracing with 'tracing on;' before executing a query. In this scenario you'll see 'Sending message to [ip address]' for each of the replicas. On Fri, Mar 7, 2014 at 5:44 PM, Jonathan Lacefield jlacefi...@datastax.com mailto:jlacefi...@datastax.com wrote: B is the answer On Mar 7, 2014, at 7:35 PM, James Lyons james.ly...@gmail.com mailto:james.ly...@gmail.com wrote: I'm wondering about the following scenario. Consider a cluster of nodes with replication say 3. When performing a read at read one consistency and lets say my client isn't smart enough to route the request to the Cassandra node housing the data at first. the contacted node acts as a coordinator and forwards the request to: A) a node that houses the data and waits for a reply, possibly timesout and re-issues to another in a failure or slow host scenario. or B) all (3) the nodes that house the data and returns after any one of them replies. I'm hoping for B... anyone know for sure?
