cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Resolved: (CASSANDRA-492) Data Center Quorum
Date Mon, 26 Oct 2009 15:08:59 GMT


Jonathan Ellis resolved CASSANDRA-492.

       Resolution: Fixed
    Fix Version/s:     (was: 0.5)

Committed, with some changes:

fixed use of generics in the new classes, especially wrt response handlers
replaced tabs with spaces
added new consistency levels to thrift
made class naming more consistent

There is one problem still to resolve; blockFor from StorageProxy is a problem.  It needs
to be determined by the replicationstrategy responsehandler only when it's useful, rather
than being computed in StorageProxy (which doesn't have all the right information anyway,
in the dc cases) and passed to getResponseHandler (where it's ignored except for one case).

> Data Center Quorum
> ------------------
>                 Key: CASSANDRA-492
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>    Affects Versions: 0.5
>         Environment: Cassandra Core Code
>            Reporter: Vijay
>            Assignee: Vijay
>            Priority: Minor
>             Fix For: 0.4
>         Attachments: cassandra-DCQuorum.patch, DC-Config.xml
>   Original Estimate: 336h
>  Remaining Estimate: 336h
> Need a Cassandra Datacenter Quorum Read and Datacenter Quorum Write.
> Add 1 new enum DC_Quorum. basically reads with this will not span across the datacenter
it will use the existing nodes in the Datacenter which has this data and read from it.
> For writes - All the data centers need to get this data, (datac enters will be configured
in the storage-config.xml and number of replicas in it). Once configured write will basically
write to all the nodes in all the datacenter but will wait only for the write in the current
> Example: We have 3 Datacenter A,B,C A has a replication factor of 3, B has 2 and C has
2. DC_Quorum write will make sure to write on 2 of 3 nodes in A.... B and C (total 4 +1) nodes
will be eventually consistent.
> Changes will be in RackAware, storage, read and write classes.
> Thanks
> Vijay

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message