cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2848) Make the Client API support passing down timeouts
Date Tue, 21 Apr 2015 07:23:00 GMT


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:
>             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

View raw message