[jira] [Created] (CASSANDRA-15252) Don't consider current keyspace in prepared statement id when the query is qualified

["Olivier Michallat (JIRA)" <ji...@apache.org>]

Olivier Michallat created CASSANDRA-15252:
---------------------------------------------

             Summary: Don't consider current keyspace in prepared statement id when the query is qualified
                 Key: CASSANDRA-15252
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15252
             Project: Cassandra
          Issue Type: Bug
            Reporter: Olivier Michallat


{{QueryProcessor.computeId}} takes into account the session's current keyspace in the MD5 digest.
{code}
String toHash = keyspace == null ? queryString : keyspace + queryString;
{code}
This is desirable for unqualified queries, because switching to a different keyspace produces a different statement. However, for a qualified query, the current keyspace makes no difference, the prepared id should always be the same.

This can lead to an infinite reprepare loop on the client. Consider this example (Java driver 3.x):
{code}
    Cluster cluster = null;
    try {
      cluster = Cluster.builder().addContactPoint("127.0.0.1").build();
      Session session = cluster.connect();

      session.execute(
          "CREATE KEYSPACE IF NOT EXISTS test WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1}");
      session.execute("CREATE TABLE IF NOT EXISTS test.foo(k int PRIMARY KEY)");

      PreparedStatement pst = session.prepare("SELECT * FROM test.foo WHERE k=?");

      // Drop and recreate the table to invalidate the prepared statement server-side
      session.execute("DROP TABLE test.foo");
      session.execute("CREATE TABLE test.foo(k int PRIMARY KEY)");

      session.execute("USE test");

      // This will try to reprepare on the fly
      session.execute(pst.bind(0));
    } finally {
      if (cluster != null) cluster.close();
    }
{code}
When the driver goes to execute the bound statement (last line before the finally block), it will get an UNPREPARED response because the statement was evicted from the server cache (as a result of dropping the table earlier).
In those cases, the driver recovers transparently by sending another PREPARE message and retrying the bound statement.
However, that second PREPARE cached the statement under a different id, because we switched to another keyspace. Yet the driver is still using the original id (stored in {{pst}}) when it retries, so it will get UNPREPARED again, etc.

I would consider this low priority because issuing a {{USE}} statement after having prepared statements is a bad idea to begin with. And even if we fix the generated id for qualified query strings, the issue will remain for unqualified ones.

We'll add a check in the driver to fail fast and avoid the infinite loop if the id returned by the second PREPARE doesn't match the original one. That might be enough to cover this issue.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org