[
https://issues.apache.org/jira/browse/CASSANDRA-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035192#comment-16035192
]
Randy Fradin commented on CASSANDRA-8119:
-----------------------------------------
I'm not sure how complicated the UDF approach is either. An
interface/stragey-class type approach is probably good enough, e.g. something
like this:
(a) Create an interface e.g. IConsistencyLevel that is basically all the public
method signatures in the ConsistencyLevel interface.
(b) Add to AbstractReplicationStrategy a getCustomReadConsistency() and a
getCustomWriteConsistency() method that each return an instance of
IConsistencyLevel (default implementations can throw
UnsupportedOperationException, or just implement a commonly used CL like QUORUM
or ONE).
(c) Add new consistency levels CUSTOM_READ and CUSTOM_WRITE to the
ConsistencyLevel enum. Each method of ConsistencyLevel would defer to the
corresponding method from the replication strategy class of the target
keyspace. Or just one CUSTOM level that would choose the appropriate
IConsistencyLevel instance from the keyspace replication strategy based on the
type of operation being performed.
Of course that's only part of the work, also the blockFor method of
ConsistencyLevel would need to have the return type changed from int to match
the return type of the function that was originally pitched as a UDF, i.e. set
of (node_set, num_replies) tuples, plus # of sets that must be satisfied if
that's deemed a worthwhile addition (otherwise it's assumed they all need to be
satisfied). Then each path that calls blockFor would need to be fixed to
respect the new return type, since they all just expect a simple # to wait for
(with the exception of EACH_QUORUM which has special logic). I haven't really
looked how complicated this part would be, hopefully not too involved though.
Then someone who wants to use this would just need to extend their replication
strategy class of choice (presumably NetworkTopologyStrategy), include it in
the definition of the keyspace, and then use the CUSTOM or
CUSTOM_READ/CUSTOM_WRITE CLs from the client.
This is my rough idea of how to implement this feature, would love to hear
feedback from anyone who has more knowledge of the codebase.
> More Expressive Consistency Levels
> ----------------------------------
>
> Key: CASSANDRA-8119
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8119
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL
> Reporter: Tyler Hobbs
> Fix For: 4.x
>
>
> For some multi-datacenter environments, the current set of consistency levels
> are too restrictive. For example, the following consistency requirements
> cannot be expressed:
> * LOCAL_QUORUM in two specific DCs
> * LOCAL_QUORUM in the local DC plus LOCAL_QUORUM in at least one other DC
> * LOCAL_QUORUM in the local DC plus N remote replicas in any DC
> I propose that we add a new consistency level: CUSTOM. In the v4 (or v5)
> protocol, this would be accompanied by an additional map argument. A map of
> {DC: CL} or a map of {DC: int} is sufficient to cover the first example. If
> we accept a special keys to represent "any datacenter", the second case can
> be handled. A similar technique could be used for "any other nodes".
> I'm not in love with the special keys, so if anybody has ideas for something
> more elegant, feel free to propose them. The main idea is that we want to be
> flexible enough to cover any reasonable consistency or durability
> requirements.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
