[
https://issues.apache.org/jira/browse/CASSANDRA-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14504494#comment-14504494
]
Sylvain Lebresne commented on CASSANDRA-2848:
---------------------------------------------
bq. Would it make sense to use CASSANDRA-8553?
I'd rather not. I'd prefer keeping the custom payload really custom and never
use it for anything Cassandra. And honestly, the protocol change for this
(using the remaining flag) is really not a big deal so it's not like we need to
look for alternatives.
One thing worth mentioning on this issue however is that currently C* doesn't
respects timeouts too well. Typically, any query with a digest mismatch could
take closer to twice the configured timeout, and with short read retries that
can be even worth. And some practical experience with the java driver has shown
that it's not a theoretical problem: it's relatively easy to have C* take way
longer than the configured timeout to answer (as in multiple seconds more than
the configured timeout). So I'm left wondering if we shouldn't fix that first,
having timeouts really be a reasonably precise upper-bound on when C* will
respond to a user query, before allowing per-query timeouts?
> 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)
