cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CASSANDRA-3199) Counter write protocol: have the coordinator (instead of first replica) waits for replica responses directly
Date Fri, 25 Jan 2013 21:37:12 GMT

     [ 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

Mime
View raw message