[
https://issues.apache.org/jira/browse/CASSANDRA-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14504970#comment-14504970
]
Sylvain Lebresne commented on CASSANDRA-2848:
---------------------------------------------
I see what you did there :)
Unfortunately:
# digests are far from being the only problem. Short reads are another, but
more importantly, any range query is pretty much a free for all as far as
timeouts are concerned since we basically reset the timeout for every range
(modulo the concurrency factor, but that can very well be 1) and there can be
very many range with vnodes. In practice, I suspect its range queries that are
more often the culprit when the timeout is not respected.
# I'm sure we can be smarter than "halve the timeout when digests are involved
in case we need to redo it". For instance, we could mark the starting of a
query and pass that down to the {{ReadCallback}}, so that it waits for
{{timeout - (now - queryStart)}}. I don't think it would be that weird (outside
of the fact we'd have to pass {{qeryStart}} down the {{ReadCallback}}).
> Make the Client API support passing down timeouts
> -------------------------------------------------
>
> Key: CASSANDRA-2848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2848
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Chris Goffinet
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 3.1
>
>
> Having a max server RPC timeout is good for worst case, but many applications
> that have middleware in front of Cassandra, might have higher timeout
> requirements. In a fail fast environment, if my application starting at say
> the front-end, only has 20ms to process a request, and it must connect to X
> services down the stack, by the time it hits Cassandra, we might only have
> 10ms. I propose we provide the ability to specify the timeout on each call we
> do optionally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
