[jira] [Created] (CASSANDRA-10021) Losing writes in a single-node cluster
Jeremy Schlatter created CASSANDRA-10021: Summary: Losing writes in a single-node cluster Key: CASSANDRA-10021 URL: https://issues.apache.org/jira/browse/CASSANDRA-10021 Project: Cassandra Issue Type: Bug Environment: I have been testing this against Docker's official Cassandra image. Reporter: Jeremy Schlatter Attachments: cpp-repro.zip, go-repro.zip I am able to reliably reproduce write losses in the following circumstances: * Set up a single-node cluster. * Create keyspace with SimpleStrategy, replication_factor = 1. * Create a table with a float field. * Send an UPDATE command to set the float value on a row. * After the command returns, immediately send another UPDATE to set the float value to something _smaller_ than the first value. * The second UPDATE is sometimes lost. Reproduction code attached. There are two implementations: one in Go and one in C++. They do the same thing -- I implemented both to rule out a bug in the client library. For both cases, you can reproduce by doing the following: 1. docker run --name repro-cassandra --rm cassandra:2.0.14 (or any other Cassandra version) 2. Download and unzip one of the zip files, and change to its directory. 3. docker build -t repro . 4. docker run --link repro-cassandra:cassandra --rm repro The reproduction code will repeatedly run two UPDATEs followed by a SELECT until it detects a lost write, and then print: "Lost a write. Got 20.50, want 10.50" This may be fixed in 2.1.8 because I have not been able to reproduce it in that version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10021) Losing writes in a single-node cluster
[ https://issues.apache.org/jira/browse/CASSANDRA-10021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Schlatter updated CASSANDRA-10021: - Environment: Docker images (was: I have been testing this against Docker's official Cassandra image.) > Losing writes in a single-node cluster > -- > > Key: CASSANDRA-10021 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10021 > Project: Cassandra > Issue Type: Bug > Environment: Docker images >Reporter: Jeremy Schlatter > Attachments: cpp-repro.zip, go-repro.zip > > > I am able to reliably reproduce write losses in the following circumstances: > * Set up a single-node cluster. > * Create keyspace with SimpleStrategy, replication_factor = 1. > * Create a table with a float field. > * Send an UPDATE command to set the float value on a row. > * After the command returns, immediately send another UPDATE to set the float > value to something _smaller_ than the first value. > * The second UPDATE is sometimes lost. > Reproduction code attached. There are two implementations: one in Go and one > in C++. They do the same thing -- I implemented both to rule out a bug in the > client library. For both cases, you can reproduce by doing the following: > 1. docker run --name repro-cassandra --rm cassandra:2.0.14 > (or any other Cassandra version) > 2. Download and unzip one of the zip files, and change to its directory. > 3. docker build -t repro . > 4. docker run --link repro-cassandra:cassandra --rm repro > The reproduction code will repeatedly run two UPDATEs followed by a SELECT > until it detects a lost write, and then print: > "Lost a write. Got 20.50, want 10.50" > This may be fixed in 2.1.8 because I have not been able to reproduce it in > that version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7256) Error when dropping keyspace.
[
https://issues.apache.org/jira/browse/CASSANDRA-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14158578#comment-14158578
]
Jeremy Schlatter commented on CASSANDRA-7256:
-
I just encountered this issue with Cassandra 2.0.9. I have a 1-node cluster
running in a virtual machine on my laptop. I am writing a unit test that
creates and drops a keyspace on every test. At some point while running it I
got:
{code}
java.lang.RuntimeException: java.util.concurrent.ExecutionException:
java.lang.IllegalStateException: One row required, 0 found`
{code}
while trying to drop the keyspace. The keyspace seems to still exist -- I can
see it with "desc keyspaces" and "desc keyspace " in cqlsh. But
I am unable to drop it. Running "drop keyspace " in cqlsh yields:
{panel:bgColor=#F5F5F5}
cqlsh> drop keyspace my_test_suite;
{color:red}*TSocket read 0 bytes*{color}
{panel}
In case it's helpful, here are some other version numbers, as printed by cqlsh:
cqlsh 4.1.1 | Cassandra 2.0.9 | CQL spec 3.1.1 | Thrift protocol 19.39.0
> Error when dropping keyspace.
> ---
>
> Key: CASSANDRA-7256
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7256
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: ubuntu 3 nodes (had 3 more in 2nd datacenter but removed
> it)
>Reporter: Steven Lowenthal
>Assignee: Aleksey Yeschenko
>
> created a 3 node datacenter called existing.
> ran cassandra-stress:
> {{cassandra-stress -R NetworkTopologyStrategy -O existing:2 -d existing0 -n
> 200 -k}}
> Added a 2nd datacenter called new with 3 nodes started it with
> {{auto_bootstrap: false}}
> {code}
> alter keyspace "Keyspace1" with replication =
> {'class':'NetworkTopologyStrategy','existing':2,'new':2};
> {code}
> I then discovered that cassandra-stress --operation=read failed with
> LOCAL_QUORUM if a node was down in the local datacenter - this occured in
> both, but should not have, so decided to try again.
> I shut down the new datacenter and removed all 3 nodes. I then tried to drop
> the Keyspace1 keyspace. cqlsh disconnected, and the log shows the error
> below.
> {code}
> ERROR [MigrationStage:1] 2014-05-16 23:57:03,085 CassandraDaemon.java (line
> 198) Exception in thread Thread[MigrationStage:1,5,main]
> java.lang.IllegalStateException: One row required, 0 found
> at org.apache.cassandra.cql3.UntypedResultSet.one(UntypedResultSet.java:53)
> at org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:263)
> at org.apache.cassandra.db.DefsTables.mergeKeyspaces(DefsTables.java:227)
> at org.apache.cassandra.db.DefsTables.mergeSchema(DefsTables.java:182)
> at
> org.apache.cassandra.service.MigrationManager$2.runMayThrow(MigrationManager.java:303)
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
