[ 
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)

Reply via email to