Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 11 Aug 2016 01:36:20 +0000 (UTC)
From: "Geoffrey Yu (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12991380.1469090597000.278429.1470879380590@Atlassian.JIRA>
In-Reply-To: <JIRA.12991380.1469090597000@Atlassian.JIRA>
References: <JIRA.12991380.1469090597000@Atlassian.JIRA> <JIRA.12991380.1469090597183@arcas>
Subject: [jira] [Commented] (CASSANDRA-12256) Properly respect the request
 timeouts
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 11 Aug 2016 01:36:22 -0000


    [ https://issues.apache.org/jira/browse/CASSANDRA-12256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15416338#comment-15416338 ] 

Geoffrey Yu commented on CASSANDRA-12256:
-----------------------------------------

Thanks for the review! I looked through the test results and it seems like there are quite a few failures that are timeouts. I'll take a look and see what I can do. 

> Properly respect the request timeouts
> -------------------------------------
>
>                 Key: CASSANDRA-12256
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12256
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>            Assignee: Geoffrey Yu
>             Fix For: 3.x
>
>         Attachments: 12256-trunk.txt
>
>
> We have a number of {{request_timeout_*}} option, that probably every user expect to be an upper bound on how long the coordinator will wait before timeouting a request, but it's actually not always the case, especially for read requests.
> I believe we don't respect those timeout properly in at least the following cases:
> * On a digest mismatch: in that case, we reset the timeout for the data query, which means the overall query might take up to twice the configured timeout before timeouting.
> * On a range query: the timeout is reset for every sub-range that is queried. With many nodes and vnodes, a range query could span tons of sub-range and so a range query could take pretty much arbitrary long before actually timeouting for the user.
> * On short reads: we also reset the timeout for every short reads "retries".
> It's also worth noting that even outside those, the timeouts don't take most of the processing done by the coordinator (query parsing and CQL handling for instance) into account.
> Now, in all fairness, the reason this is this way is that the timeout currently are *not* timeout for the full user request, but rather how long a coordinator should wait on any given replica for any given internal query before giving up. *However*, I'm pretty sure this is not what user intuitively expect and want, *especially* in the context of CASSANDRA-2848 where the goal is explicitely to have an upper bound on the query from the user point of view.
> So I'm suggesting we change how those timeouts are handled to really be timeouts on the whole user query.
> And by that I basically just mean that we'd mark the start of each query as soon as possible in the processing, and use that starting time as base in {{ReadCallback.await}} and {{AbstractWriteResponseHandler.get()}}. It won't be perfect in the sense that we'll still only possibly timeout during "blocking" operations, so typically if parsing a query takes more than your timeout, you still won't timeout until that query is sent, but I think that's probably fine in practice because 1) if you timeouts are small enough that this matter, you're probably doing it wrong and 2) we can totally improve on that later if needs be.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)