[
https://issues.apache.org/jira/browse/CASSANDRA-6837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940383#comment-13940383
]
Sylvain Lebresne commented on CASSANDRA-6837:
---------------------------------------------
At the risk of sounding obtuse, we use "serial_consistency" both in thrift and
in the native protocol spec. And truth is, while maybe not perfect, I do think
it's better than paxos_consistency because that would be leaking implementation
details and we've always said that the use of Paxos was an implementation
detail we didn't wanted to leak. It also happen that I don't really see the
problem with serial_consistency. The comment in cassandra.thrift describe it
this way
{quote}
The first one, serial_consistency_level, simply indicates the level of
serialization required. This can be either ConsistencyLevel.SERIAL or
ConsistencyLevel.LOCAL_SERIAL
{quote}
and to me that sounds relatively sensible. Of course, we can call it "serial
consistency" externally but "paxos consistency" internally, but that feels a
bit inconsistent for no good reason.
Anyway, all this to say that imo serial_consistency is better than
paxos_consistency at least externally because it doesn't leak implementation
details, and that it follows to me that there is no point in making it
different internally. Nor do I think that serial_consistency is so bad that we
should bother finding something else. Those arguments and opinion being made,
if you still think it's worth renaming, I won't fight it, and feel free to go
ahead. It's orthogonal to this issue however, the patch here didn't introduced
the serial_consistency naming.
> Batch CAS does not support LOCAL_SERIAL
> ---------------------------------------
>
> Key: CASSANDRA-6837
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6837
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Nicolas Favre-Felix
> Assignee: Sylvain Lebresne
> Fix For: 2.0.7
>
> Attachments: 6837.txt
>
>
> The batch CAS feature introduced in Cassandra 2.0.6 does not support the
> LOCAL_SERIAL consistency level, and always uses SERIAL.
> Create a cluster with 4 nodes with the following topology:
> {code}
> Datacenter: DC2
> ===============
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns Host ID
> Rack
> UN 127.0.0.3 269 KB 256 26.3% ae92d997-6042-42d9-b447-943080569742
> RAC1
> UN 127.0.0.4 197.81 KB 256 25.1% 3edc92d7-9d1b-472a-8452-24dddbc4502c
> RAC1
> Datacenter: DC1
> ===============
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns Host ID
> Rack
> UN 127.0.0.1 226.92 KB 256 24.8% dbc17bd7-1ede-47a2-9b31-6063752d6eb3
> RAC1
> UN 127.0.0.2 179.27 KB 256 23.7% bb0ad285-34d2-4989-a664-b068986ab6fa
> RAC1
> {code}
> In cqlsh:
> {code}
> cqlsh> CREATE KEYSPACE foo WITH replication = {'class':
> 'NetworkTopologyStrategy', 'DC1': 2, 'DC2': 2};
> cqlsh> USE foo;
> cqlsh:foo> CREATE TABLE bar (x text, y bigint, z bigint, t bigint, PRIMARY
> KEY(x,y));
> {code}
> Kill nodes 127.0.0.3 and 127.0.0.4:
> {code}
> Datacenter: DC2
> ===============
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns Host ID
> Rack
> DN 127.0.0.3 262.37 KB 256 26.3% ae92d997-6042-42d9-b447-943080569742
> RAC1
> DN 127.0.0.4 208.04 KB 256 25.1% 3edc92d7-9d1b-472a-8452-24dddbc4502c
> RAC1
> Datacenter: DC1
> ===============
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address Load Tokens Owns Host ID
> Rack
> UN 127.0.0.1 214.82 KB 256 24.8% dbc17bd7-1ede-47a2-9b31-6063752d6eb3
> RAC1
> UN 127.0.0.2 178.23 KB 256 23.7% bb0ad285-34d2-4989-a664-b068986ab6fa
> RAC1
> {code}
> Connect to 127.0.0.1 in DC1 and run a CAS batch at
> CL.LOCAL_SERIAL+LOCAL_QUORUM:
> {code}
> final Cluster cluster = new Cluster.Builder()
> .addContactPoint("127.0.0.1")
> .withLoadBalancingPolicy(new DCAwareRoundRobinPolicy("DC1"))
> .build();
> final Session session = cluster.connect("foo");
> Batch batch = QueryBuilder.batch();
> batch.add(new SimpleStatement("INSERT INTO bar (x,y,z) VALUES ('abc',
> 123, 1) IF NOT EXISTS"));
> batch.add(new SimpleStatement("UPDATE bar SET t=2 WHERE x='abc' AND
> y=123"));
> batch.setConsistencyLevel(ConsistencyLevel.LOCAL_QUORUM);
> batch.setSerialConsistencyLevel(ConsistencyLevel.LOCAL_SERIAL);
> session.execute(batch);
> {code}
> The batch fails with:
> {code}
> Caused by: com.datastax.driver.core.exceptions.UnavailableException: Not
> enough replica available for query at consistency SERIAL (3 required but only
> 2 alive)
> at com.datastax.driver.core.Responses$Error$1.decode(Responses.java:44)
> at com.datastax.driver.core.Responses$Error$1.decode(Responses.java:33)
> at
> com.datastax.driver.core.Message$ProtocolDecoder.decode(Message.java:182)
> at
> org.jboss.netty.handler.codec.oneone.OneToOneDecoder.handleUpstream(OneToOneDecoder.java:66)
> ... 21 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
