Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C440E1107F for ; Sat, 2 Aug 2014 11:05:37 +0000 (UTC) Received: (qmail 30367 invoked by uid 500); 2 Aug 2014 11:05:33 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 30325 invoked by uid 500); 2 Aug 2014 11:05:33 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 30314 invoked by uid 99); 2 Aug 2014 11:05:33 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Aug 2014 11:05:33 +0000 X-ASF-Spam-Status: No, hits=0.3 required=5.0 tests=FREEMAIL_REPLY,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of duncan.sands@gmail.com designates 209.85.212.176 as permitted sender) Received: from [209.85.212.176] (HELO mail-wi0-f176.google.com) (209.85.212.176) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Aug 2014 11:05:27 +0000 Received: by mail-wi0-f176.google.com with SMTP id bs8so2600686wib.9 for ; Sat, 02 Aug 2014 04:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ll5USi56nBaGHUBl0qghkRiL4C37233Bn0nMyMzljhI=; b=lUMgqfGn+Hfecp1Mr4qW1bzKi1uqtIOK99l3TfBj6AnzXDDRIQTcy97CxdnsBoc3OO n41s0zoSxBSiBPYJdswlATHlUfTeH2PMCgycWoZgvP5kdtAY+lqwIliHTdDqDfp4S8Da +iqraL2PFaHEQs162Dk3f7DFd4iJZbAfJc0Iolgd14Gbz5UCQtG1kMmDWCRIKLybSQNn vdcZ4tGI9MraaPgtbpdw8AmRG4waeXnMP++ASpnUL6+LLFJREMlYM44LuKA28uUH4xY0 1tIRgXhyYYUzOpMh1jtpWpo+HxSrujtnDot2NDA1nmWCGjS+Ydyw8K/zI1bE88GPvcsg Vc1g== X-Received: by 10.194.92.115 with SMTP id cl19mr16896736wjb.29.1406977503382; Sat, 02 Aug 2014 04:05:03 -0700 (PDT) Received: from [192.168.1.198] (095-097-251-138.static.chello.nl. [95.97.251.138]) by mx.google.com with ESMTPSA id kr5sm27557734wjc.27.2014.08.02.04.05.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Aug 2014 04:05:02 -0700 (PDT) Message-ID: <53DCC5DA.8060402@gmail.com> Date: Sat, 02 Aug 2014 13:04:58 +0200 From: Duncan Sands User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: user@cassandra.apache.org Subject: Re: Occasional read timeouts seen during row scans References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hi Clint, is time correctly synchronized between your nodes? Ciao, Duncan. On 02/08/14 02:12, Clint Kelly wrote: > BTW a few other details, sorry for omitting these: > > * We are using version 2.0.4 of the Java driver > * We are running against Cassandra 2.0.9 > * I tried messing around with the page size (even reducing it down to a single > record) and that didn't seem to help (in the cases where I was observing the > timeout) > > Best regards, > Clint > > > > On Fri, Aug 1, 2014 at 5:02 PM, Clint Kelly > wrote: > > Hi everyone, > > I am seeing occasional read timeouts during multi-row queries, but I'm > having difficulty reproducing them or understanding what the problem > is. > > First, some background: > > Our team wrote a custom MapReduce InputFormat that looks pretty > similar to the DataStax InputFormat except that it allows queries that > touch multiple CQL tables with the same PRIMARY KEY format (it then > assembles together results from multiple tables for the same primary > key before sending them back to the user in the RecordReader). > > During a large batch job in a cluster and during some integration > tests, we see errors like the following: > > com.datastax.driver.core.exceptions.ReadTimeoutException: Cassandra > timeout during read query at consistency ONE (1 responses were > required but only 0 replica responded) > > Our queries look like this: > > SELECT token(eid_component), eid_component, lg, family, qualifier, > version, value FROM "kiji_it0"."t_foo" WHERE lg=? AND family=? AND > qualifier=? AND token(eid_component) >= ? AND token(eid_component) <= > ?ALLOW FILTERING; > > Our tables look like the following: > > CREATE TABLE "kiji_it0"."t_foo" ( > eid_component varchar, > lg varchar, > family blob, > qualifier blob, > version bigint, > value blob, > PRIMARY KEY ((eid_component), lg, family, qualifier, version)) > WITH CLUSTERING ORDER BY (lg ASC, family ASC, qualifier ASC, version DESC); > > with an additional index on the "lg" column (the lg column is > *extremely* low cardinality). > > (FWIW I realize that having "ALLOW FILTERING" is potentially a Very > Bad Idea, but we are building a framework on top of Cassandra and > MapReduce that allows our users to occasionally make queries like > this. We don't really mind taking a performance hit since these are > batch jobs. We are considering eventually supporting some automatic > denormalization, but have not done so yet.) > > If I change the query above to remove the WHERE clauses, the errors go away. > > I think I understand the problem here---there are some rows that have > huge amounts of data that we have to scan over, and occasionally those > scans take so long that there is a timeout. > > I have a couple of questions: > > 1. What parameters in my code or in the Cassandra cluster do I need to > adjust to get rid of these timeouts? Our table layout is designed > such that its real-time performance should be pretty good, so I don't > mind if the batch queries are a little bit slow. Do I need to change > the read_request_timeout_in_ms parameter? Or something else? > > 2. I have tried to create a test to reproduce this problem, but I have > been unable to do so. Any suggestions on how to do this? I tried > creating a table similar to that described above and filling in a huge > amount of data for some rows to try to increase the amount of space > that we'd need to skip over. I also tried reducing > read_request_timeout_in_ms from 5000 ms to 50 ms and still no dice. > > Let me know if anyone has any thoughts or suggestions. At a minimum > I'd like to be able to reproduce these read timeout errors in some > integration tests. > > Thanks! > > Best regards, > Clint > >