[
https://issues.apache.org/jira/browse/CASSANDRA-11288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Lockwood updated CASSANDRA-11288:
----------------------------------------
Description:
As part of a schema migration operation, our application is calling the
following operations on the Java driver consecutively:
{quote}
session.execute("DROP TABLE table_name");
session.execute("CREATE TABLE table_name (...)");
{quote}
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.
{{c.d.d.c.ControlConnection - [] [] [] [] [] [] [] [] Checking for schema
agreement: versions are [02bce936-fddd-3bef-bb54-124d31bede57]}}.
(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?
was:
As part of a schema migration operation, our application is calling the
following operations on the Java driver consecutively:
{{session.execute("DROP TABLE table_name");
session.execute("CREATE TABLE table_name (...)");}}
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.
{{c.d.d.c.ControlConnection - [] [] [] [] [] [] [] [] Checking for schema
agreement: versions are [02bce936-fddd-3bef-bb54-124d31bede57]}}.
(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?
> 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
> Connecting with Datastax Java driver 2.1.8
> Reporter: Oliver Lockwood
> Priority: Minor
>
> As part of a schema migration operation, our application is calling the
> following operations on the Java driver consecutively:
> {quote}
> session.execute("DROP TABLE table_name");
> session.execute("CREATE TABLE table_name (...)");
> {quote}
> 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.
> {{c.d.d.c.ControlConnection - [] [] [] [] [] [] [] [] Checking for schema
> agreement: versions are [02bce936-fddd-3bef-bb54-124d31bede57]}}.
> (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)
