You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Andy Tolbert (JIRA)" <ji...@apache.org> on 2016/09/22 15:08:20 UTC

[jira] [Created] (CASSANDRA-12686) Communicate timeouts and other driver relevant options in SUPPORTED response or some other mechanism

Andy Tolbert created CASSANDRA-12686:
----------------------------------------

             Summary: Communicate timeouts and other driver relevant options in SUPPORTED response or some other mechanism
                 Key: CASSANDRA-12686
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12686
             Project: Cassandra
          Issue Type: Improvement
            Reporter: Andy Tolbert


It would be really useful if driver clients had a mechanism to understand what the configured timeouts on the C* side are.

Ideally a driver should be configured in such a way that it's client timeout is greater than the C* timeouts ({{write_request_timeout_in_ms}}, {{read_request_timeout_in_ms}}, etc.) so its retry policy may make the appropriate decision based on the kind of timeout received from cassandra.   This is why most driver clients have a client timeout of 12 seconds.   If the client knew the server timeouts, it could adjust its client timeout accordingly.

At the moment, the only place I think where this could be communicated is through a {{SUPPORTED}} message when the client sends an {{OPTIONS}} message, but that could be viewed as awkward.  Also consider that some clients use the {{OPTIONS}} message as a form of heartbeat, so adding more to a {{SUPPORTED}} message could add some (likely trivial) data on the wire between server and client.

Alternatively, it could also be interesting if the client could configure the timeout on the server end (with some ceiling set by C*).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)