[ https://issues.apache.org/jira/browse/CASSANDRA-11288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15175405#comment-15175405 ]
Sylvain Lebresne commented on CASSANDRA-11288: ---------------------------------------------- It would be easier to track/test if you were to share your reproduction script. I'll also note that 2.0 is no supported anymore, so we'll want to check if that still reproduce on 2.1. > Schema agreement appears to be false positive following a DROP TABLE command > ---------------------------------------------------------------------------- > > Key: CASSANDRA-11288 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11288 > Project: Cassandra > Issue Type: Bug > Environment: Cassandra 2.0.14.439 (DSE 4.6.7) > 2 nodes OR 4 nodes > Connecting with Datastax Java driver 2.1.8 OR 2.0.12 OR 2.1.4 OR 2.1.9 OR > 3.0.0 > Reporter: Oliver Lockwood > > As part of a schema migration operation, our application is calling the > following operations on the Java driver consecutively: > {noformat} > session.execute("DROP TABLE table_name"); > session.execute("CREATE TABLE table_name (...)"); > {noformat} > The second of these sometimes fails with a {{DriverException}} whose message > is "Table keyspace.table_name already exists". > In the schema migration operation, there's 4 of these drop/create pairings > and, although it's random which exact one fails, we've never managed to get > further than the third operation in approximately 10 attempts - so there's a > reasonably high proportion of failure. > I don't believe this is a driver issue because the driver is checking for > schema agreement (as per > https://github.com/datastax/java-driver/blob/2.1/driver-core/src/main/java/com/datastax/driver/core/ControlConnection.java#L701) > and we are seeing a log message to that effect. > {noformat} > c.d.d.c.ControlConnection - [] [] [] [] [] [] [] [] Checking for schema > agreement: versions are [02bce936-fddd-3bef-bb54-124d31bede57] > {noformat} > This log message appears in between our own logs which say "Executing > statement DROP TABLE..." and "Executing statement CREATE TABLE...", so we can > be reasonably sure this log message refers to the DROP operation being viewed > as "in agreement". > Could this be a bug in the Cassandra server erroneously reporting that the > schemas are in agreement across the 2 nodes when, in fact, they are not? -- This message was sent by Atlassian JIRA (v6.3.4#6332)