[jira] [Updated] (CASSANDRA-12686) Communicate timeouts and other driver relevant options in SUPPORTED response or some other mechanism
[
https://issues.apache.org/jira/browse/CASSANDRA-12686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-12686:
-
Component/s: Observability
CQL
> 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
> Components: CQL, Observability
>Reporter: Andy Tolbert
>Priority: Major
> Labels: client-impacting
>
> 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
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12686) Communicate timeouts and other driver relevant options in SUPPORTED response or some other mechanism
[
https://issues.apache.org/jira/browse/CASSANDRA-12686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-12686:
-
Labels: client-impacting (was: )
> 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
> Labels: client-impacting
>
> 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)
