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 Wed, 20 Jul 2016 08:53:20 GMT


Sylvain Lebresne commented on CASSANDRA-2848:

bq. Also this is strictly better than what we have now.

I disagree. As said above, giving more ways for user to get badly surprised is not better
in my book. More precisely, the fact that the timeouts are currently global is probably why
people don't rely on it too much, and why the fact that they are not always respected is lost
to most users. If you start allowing a per-query timeout, you can be sure that user will start
relying on them, and get nastily surprised. And it's not because something is off by default
that it's ok to have it broken (and, it should be clear by now, it's imo broken unless the
timeout are at least somewhat seriously respected).

So I maintain my arguments and "vote".

But I will also note that whatever what thinks of those points, this will still have to wait
for 4.0 due to the protocol changes, which is still months away. So if someone is motivated
for having that feature in, there is plenty of time for fixing the timeouts first. I'm not
even saying I won't find some time to do so myself in the coming months if no-one beats me
to it since this has been bothering me for a while.

> Make the Client API support passing down timeouts
> -------------------------------------------------
>                 Key: CASSANDRA-2848
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Chris Goffinet
>            Assignee: Geoffrey Yu
>            Priority: Minor
>             Fix For: 3.x
>         Attachments: 2848-trunk.txt
> 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