Ah FWIW I was able to reproduce the problem by reducing "range_request_timeout_in_ms." This is great since I want to increase the timeout for batch jobs where we scan a large set of rows, but leave the timeout for single-row queries alone.
Best regards, Clint On Tue, Aug 5, 2014 at 11:42 AM, Clint Kelly <clint.ke...@gmail.com> wrote: > Hi Rob, > > Thanks for your feedback. I understand that use of ALLOW FILTERING is > not a best practice. In this case, however, I am building a tool on > top of Cassandra that allows users to sometimes do things that are > less than optimal. When they try to do expensive queries like this, > I'd rather provide a higher limit before timing out, but I can't seem > to change the behavior of Cassandra by tweaking any of the parameters > in the cassandra.yaml file or in the DataStax Java driver's Cluster > object. > > FWIW these queries are also in batch jobs where we can tolerate the > extra latency. > > Thanks for your help! > > Best regards, > Clint > > > On Tue, Aug 5, 2014 at 10:54 AM, Robert Coli <rc...@eventbrite.com> wrote: >> On Tue, Aug 5, 2014 at 10:01 AM, Clint Kelly <clint.ke...@gmail.com> wrote: >>> >>> Allow me to rephrase a question I asked last week. I am performing some >>> queries with ALLOW FILTERING and getting consistent read timeouts like the >>> following: >> >> >> ALLOW FILTERING should be renamed PROBABLY TIMEOUT in order to properly >> describe its typical performance. >> >> As a general statement, if you have to ALLOW FILTERING, you are probably >> Doing It Wrong in terms of schema design. >> >> A correctly operated cluster is unlikely to need to increase the default >> timeouts. If you find yourself "needing" to do so, you are, again, probably >> Doing It Wrong. >> >> =Rob
