[jira] [Commented] (CASSANDRA-6837) Batch CAS does not support LOCAL_SERIAL
[
https://issues.apache.org/jira/browse/CASSANDRA-6837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940435#comment-13940435
]
Jonathan Ellis commented on CASSANDRA-6837:
---
fair enough
> 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
> -- AddressLoad 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
> -- AddressLoad 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
> -- AddressLoad 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
> -- AddressLoad 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)
[jira] [Commented] (CASSANDRA-6837) Batch CAS does not support LOCAL_SERIAL
[
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
> -- AddressLoad 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
> -- AddressLoad 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
> -- AddressLoad 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
> -- AddressLoad 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
[jira] [Commented] (CASSANDRA-6837) Batch CAS does not support LOCAL_SERIAL
[
https://issues.apache.org/jira/browse/CASSANDRA-6837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940139#comment-13940139
]
Jonathan Ellis commented on CASSANDRA-6837:
---
can we use paxosCL and commitCL then?
i don't like "serialCL" because serial is itself a CL value
> 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
> -- AddressLoad 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
> -- AddressLoad 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
> -- AddressLoad 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
> -- AddressLoad 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)
[jira] [Commented] (CASSANDRA-6837) Batch CAS does not support LOCAL_SERIAL
[
https://issues.apache.org/jira/browse/CASSANDRA-6837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13937631#comment-13937631
]
Sylvain Lebresne commented on CASSANDRA-6837:
-
Committed, thanks.
bq. but can we rename to commitCL instead of serialCL?
Hum, the thing is that serialCL is the CL for the paxos phase, not the one use
during the commit (it corresponds to the consistencyForPaxos argument of
SP.cas(), not to consistencyForCommit), so renaming it commitCL is probably a
bad idea. I'm fine renaming it to paxosCL or something though, I don't really
care much (though we use serialConsistency in other places already like the
native protocol, QueryOptions and in thrift/CassandraServer so if it was just
me, I'd leave it be).
> 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
> -- AddressLoad 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
> -- AddressLoad 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
> -- AddressLoad 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
> -- AddressLoad 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)
[jira] [Commented] (CASSANDRA-6837) Batch CAS does not support LOCAL_SERIAL
[
https://issues.apache.org/jira/browse/CASSANDRA-6837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935493#comment-13935493
]
Jonathan Ellis commented on CASSANDRA-6837:
---
+1, but can we rename to commitCL instead of serialCL?
> 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
> -- AddressLoad 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
> -- AddressLoad 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
> -- AddressLoad 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
> -- AddressLoad 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)
