You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Benedict (JIRA)" <ji...@apache.org> on 2014/09/17 16:19:34 UTC

[jira] [Updated] (CASSANDRA-7955) Range movements can violate consistency if RING_DELAY <= write_request_timeout_in_ms

     [ https://issues.apache.org/jira/browse/CASSANDRA-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benedict updated CASSANDRA-7955:
--------------------------------
    Description: 
Cassandra should probably refuse to start if RING_DELAY is too close to (or below) write_request_timeout_ms, because we depend on this for correctness/consistency during range movements

We should probably also consider throwing a WriteTimeoutException _even if we don't get interrupted by the timeout, since there are reasons due to scheduling or system overload this could not happen (though it is unlikely to be significant enough to have an impact, it's better safe than sorry)

  was:
Cassandra should probably refuse to start if RING_DELAY is too close to (or below) write_request_timeout_ms

We should probably also consider throwing a WriteTimeoutException _even if we don't get interrupted by the timeout, since there are reasons due to scheduling or system overload this could not happen (though it is unlikely to be significant enough to have an impact, it's better safe than sorry)


> Range movements can violate consistency if RING_DELAY <= write_request_timeout_in_ms
> ------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-7955
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7955
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Benedict
>            Priority: Minor
>
> Cassandra should probably refuse to start if RING_DELAY is too close to (or below) write_request_timeout_ms, because we depend on this for correctness/consistency during range movements
> We should probably also consider throwing a WriteTimeoutException _even if we don't get interrupted by the timeout, since there are reasons due to scheduling or system overload this could not happen (though it is unlikely to be significant enough to have an impact, it's better safe than sorry)



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