cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Blake Eggleston (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6246) EPaxos
Date Fri, 27 Feb 2015 00:31:06 GMT


Blake Eggleston commented on CASSANDRA-6246:

I just merged some commits into my CASSANDRA-6246 branch. This is the initial implementation
of the epoch, instance gc, streaming/repair, read repair, and failure recovery logic. I also
have a dtests fork that tests it here:

I still have some items I need to complete before submitting review, but nothing major (relative
to this stuff). Mostly cleaning up and refining things.

> EPaxos
> ------
>                 Key: CASSANDRA-6246
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Blake Eggleston
>            Priority: Minor
> One reason we haven't optimized our Paxos implementation with Multi-paxos is that Multi-paxos
requires leader election and hence, a period of unavailability when the leader dies.
> EPaxos is a Paxos variant that requires (1) less messages than multi-paxos, (2) is particularly
useful across multiple datacenters, and (3) allows any node to act as coordinator:
> However, there is substantial additional complexity involved if we choose to implement

This message was sent by Atlassian JIRA

View raw message