You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2013/01/25 22:37:12 UTC

[jira] [Resolved] (CASSANDRA-3199) Counter write protocol: have the coordinator (instead of first replica) waits for replica responses directly

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

Jonathan Ellis resolved CASSANDRA-3199.
---------------------------------------

    Resolution: Won't Fix
    
> Counter write protocol: have the coordinator (instead of first replica) waits for replica responses directly
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-3199
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3199
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Sylvain Lebresne
>            Priority: Minor
>              Labels: counters
>
> Current counter write protocol is this (where we take the case of write coordinator != first replica):
>   # coordinator forward write request to first replica
>   # first replica write locally and replicate to other replica
>   # first replica waits for enough answers from the other replica to satisfy the consistency level
>   # first replica acks the coordinator that completes the write to the client
> This ticket proposes to modify this protocol to:
>   # coordinator forward write request to first replica
>   # first replica write locally, acks the coordinator for its own write and replicate to other replica
>   # other replica respond directly to coordinator
>   # once coordinator has enough responses, it completes the write
> I see 2 advantages to this new protocol:
>   * it should be at tad faster since it parallelizes wire transfer better
>   * it woud make TimeoutException a bit less likely and more importantly, a TimeoutException would much more likely mean that the write hasn't been persisted. Indeed, in the current protocol, once the first replica has send the write to the other replica, it has to wait for the replica answers and answer the coordinator. If it dies during that time, we will return a TimeoutException, even though the first replica died after having done it's main job.
> The cons is that this adds a bit of complexity. In particular, the "other replica" would have to answer to the coordinator for a query that has been issued by the first replica.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira