cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Igor Zubchenok (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-6246) EPaxos
Date Wed, 16 Aug 2017 00:46:02 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128159#comment-16128159
] 

Igor Zubchenok edited comment on CASSANDRA-6246 at 8/16/17 12:45 AM:
---------------------------------------------------------------------

I would like to try, but I'm not familiar with Cassandra source code. :( Isn't it easier to
implement the patch again, but without rebase from 4 year old code?

BTW, I'm looking for a solution to implement a *reference counter based on Cassandra*. 

My first reference counter implementation has been made on counter columns, but unfortunately
it had been ruined with tombstones issue - when a counter get back to zero, I cannot delete
nor compact it.

My guess was that the lightweight Cassandra transactions can do a very good job for my task.
I was so naive and now I have an issue with WriteTimeoutException and inconsistent state.


The only workaround I came up with today is to do an exclusive lock that can be easily made
with LWT with TTL, and subsequent change of a value, but it will have much more greater performance
hit. I'm still looking for a good solution on that with Cassandra.

Currently I'm naive again and expecting that EPaxos will help me, but seems it will never-never
be merged and released.

Dear community, do you have any idea?

P.S. Huge thanks and warm hugs to everyone who answers me!


was (Author: geagle):
I would like to try, but I'm not familiar with Cassandra source code. :( Isn't it easier to
implement the patch again, but without rebase from 4 year old code?

BTW, I'm looking for a solution to implement a *reference counter based on Cassandra*. 

My first reference counter implementation has been made on counter columns, but unfortunately
it had been ruined with tombstones issue - when a counter get back to zero, I cannot delete
nor compact it.

My guess was that the lightweight Cassandra transactions can do a very good job for my task.
I was so naive and now I have an issue with WriteTimeoutException and inconsistent state.


The only workaround I came up with today is to do an exclusive lock that can be easily made
with LWT with TTL, and subsequent change of a value, but it will have much more greater performance
hit. I'm still looking for a good solution on that with Cassandra.

Currently I'm naive again and expecting that EPaxos will help me, but seems it will never-never
be merged and released.

Dear community, do you have any idea?

Huge thanks to everyone who answers me.

> EPaxos
> ------
>
>                 Key: CASSANDRA-6246
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6246
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Jonathan Ellis
>            Assignee: Blake Eggleston
>              Labels: messaging-service-bump-required
>             Fix For: 4.x
>
>
> 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: http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf
> However, there is substantial additional complexity involved if we choose to implement
it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message