cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7902) Introduce the ability to ignore RR based on consistencfy
Date Sat, 07 Mar 2015 01:11:38 GMT


Aleksey Yeschenko commented on CASSANDRA-7902:

The primary reason for going LOCAL_* CL for reads is to avoid latency hit, so I still think
that crossing local dc for RR there is at least somewhat surprising to some. Not limiting
RR to local for LOCAL_* CL was an oversight - I don't remember the issue being raised at the
time at all.

Now, swapping the default global/local RR chances in CASSANDRA-7320 was definitely the right
thing to do, but I believe it's still orthogonal to this ticket. I don't have much data either,
but tying RR candidate sourcing to per-request CL vs. just the per-table config does feel
more precise. It *is* reasonable to sometimes use different consistency levels on the same
table based on the data being queried. That I know, because I've done it before - and we still
do a form of that for auth, switching CL based on whether or not we are querying for the default

I will not fight strongly for it, but I really want to make this change in 3.0. Partially
because it's less surprising behavior, partially because it will simplify code a bit - but
mostly the former. It would also allow us to resolve this ticket without any extra options/levels.

Any other opinions? [~thobbs] [~jbellis] [~rssvihla]?

> Introduce the ability to ignore RR based on consistencfy
> --------------------------------------------------------
>                 Key: CASSANDRA-7902
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Brandon Williams
> There exists a case for LOCAL_* consistency levels where you really want them *local
only*.  This implies that you don't ever want to do cross-dc RR, but do for other levels.

This message was sent by Atlassian JIRA

View raw message