[
https://issues.apache.org/jira/browse/CASSANDRA-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoffrey Yu updated CASSANDRA-2848:
-----------------------------------
Status: Patch Available (was: Open)
I’ve attached a patch implementing this, and would love some feedback!
At a high level, the approach I took was to use the last flag available in the
protocol to allow a client to specify whether or not the client supplied a
timeout (as a {{long}}, in milliseconds). Cassandra will then use the minimum
of either the client specified timeout or the configured RPC timeout. The rest
of the changes were essentially for passing the client supplied timeout down to
where it’s actually needed. I also bumped the messaging service version to
allow for passing the timeout to the replica nodes as a part of
serialization/deserialization for {{ReadCommand}} and {{Mutation}}.
> 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
> 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
(v6.3.4#6332)
