cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CASSANDRA-11288) Schema agreement appears to be false positive following a DROP TABLE command
Date Wed, 02 Mar 2016 13:59:18 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-11288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Aleksey Yeschenko resolved CASSANDRA-11288.
-------------------------------------------
    Resolution: Cannot Reproduce

Closing as {{Cannot Reproduce}} in a supported C* version.

> 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)

Mime
View raw message