[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13593211#comment-13593211 ] Sylvain Lebresne commented on CASSANDRA-5062: - bq. When Acceptor receives proposal, if it doesn't check R, if Tm Tn (clock mismatch) according to paxos it needs to send it's old accepted value In my solution/proposal, a round is a fully separated Paxos instance (it's not just a proposal round for instance). Meaning that comparing a proposal timestamp Tn for Round R with a proposal timestamp Tm for another round R-1 (which is the case you are talking about) makes no sense whatsoever and is thus never done. And it doesn't break Paxos exactly because we don't mix things from 2 completely separated instance of the raw Paxos algorithm. Support CAS --- Key: CASSANDRA-5062 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Fix For: 2.0 Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit 3.jpg Strong consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5310) New authentication module does not wok in multi datacenters in case of network outage
[ https://issues.apache.org/jira/browse/CASSANDRA-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cyril Scetbon updated CASSANDRA-5310: - Attachment: auth_fix_consistency.patch Do not use QUORUM consistency with authentication New authentication module does not wok in multi datacenters in case of network outage - Key: CASSANDRA-5310 URL: https://issues.apache.org/jira/browse/CASSANDRA-5310 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.2 Environment: Ubuntu 12.04 Cluster of 16 nodes in 2 datacenters (8 nodes in each datacenter) Reporter: jal Assignee: Aleksey Yeschenko Attachments: auth_fix_consistency.patch With 1.2.2, I am using the new authentication backend PasswordAuthenticator with the authorizer CassandraAuthorizer In case of network outage, we are no more able to connect to Cassandra. Here is the error message we get when I want to connect through cqlsh: Traceback (most recent call last): File ./cqlsh, line 2262, in module main(*read_options(sys.argv[1:], os.environ)) File ./cqlsh, line 2248, in main display_float_precision=options.float_precision) File ./cqlsh, line 483, in __init__ cql_version=cqlver, transport=transport) File ./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/connection.py, line 143, in connect File ./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/connection.py, line 59, in __init__ File ./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/thrifteries.py, line 157, in establish_connection File ./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/cassandra/Cassandra.py, line 455, in login File ./../lib/cql-internal-only-1.4.0.zip/cql-1.4.0/cql/cassandra/Cassandra.py, line 476, in recv_login cql.cassandra.ttypes.AuthenticationException: AuthenticationException(why='org.apache.cassandra.exceptions.UnavailableException: Cannot achieve consistency level QUORUM') -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13593457#comment-13593457 ] Cristian Opris commented on CASSANDRA-5062: --- I understand what you mean by terminology but this is not where the confusion is coming from. My commit C1,C2 etc is your learn, agreed. My accept is your commit. It may be a bit confusing because I'm not detailing everything in the diagram So when Z goes into C1, that implies: it receives accept from Y, it commits (i.e. writes) the value locally and then it sends learn message to X and Y, which might fail without Z having any record of that. I know this is not the exact behaviour in your algoritm. I'm not sure how the leader commits (learns) the value locally, is it because it ends up calling receive(LEARN) locally (i.e. acting as acceptor as well) ? But this doesn't change my point. *My point is the learn can fail without the leader being aware, which leads to a state where each replica is at a different stage of learning. Even if the paxos round states are correct in terms of accepted values (what you call commit), they are not finished in terms of learning* Support CAS --- Key: CASSANDRA-5062 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Fix For: 2.0 Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit 3.jpg Strong consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3929) Support row size limits
[ https://issues.apache.org/jira/browse/CASSANDRA-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13593738#comment-13593738 ] Ahmet AKYOL commented on CASSANDRA-3929: [~rbranson]: thanks for the explanation. I also want to get it for free but what I tried to say is as a user, I am OK with extra cql if it's necessary . I was thinking something similar to a redis pipeline which starts with adding data with zadd and after that limiting data with zremrangeByRank as in your words if the data is time-ordered About the requirement reading the entire row, let's first revisit our use cases for this limited row size type tables. Why we want them? Most probably we already have tables for our big data (that's why we use and love C*), but we need a special cache for hot data that's why it's a blocker to move from Redis to C* for some storage. So, what about C*'s row cache ? unfortunately, not an option because we may need data from many tables or we need only (most recent) portion of the wide rows, not all of them. So,once again, what we really want from this issue is indeed, a special cache table and that's why reading the entire row is not a problem beacuse we want the entire row on memory when it's hot. once more, just my two cents, no intention to interrupt your development process. Just see me as the business (user) side and remember the principle business people and developers must work together daily throughout the project of [agile manifesto|http://agilemanifesto.org/principles.html] Support row size limits --- Key: CASSANDRA-3929 URL: https://issues.apache.org/jira/browse/CASSANDRA-3929 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: Dave Brosius Priority: Minor Labels: ponies Fix For: 2.0 Attachments: 3929_b.txt, 3929_c.txt, 3929_d.txt, 3929_e.txt, 3929_f.txt, 3929_g_tests.txt, 3929_g.txt, 3929.txt We currently support expiring columns by time-to-live; we've also had requests for keeping the most recent N columns in a row. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
