[
https://issues.apache.org/jira/browse/CASSANDRA-15252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17454909#comment-17454909
]
Ekaterina Dimitrova edited comment on CASSANDRA-15252 at 12/8/21, 1:21 AM:
---------------------------------------------------------------------------
I think also previous versions have failing rolling upgrade tests. There is
ticket CASSANDRA-17140 and I was also bisecting today as I didn't know about
[~bereng] 's findings until I read this one but I have reached to the same
conclusion that this Is where the failures started, same day. Jenkins lacks
some runs history for newer branches but looking into 3.0 now where we also
have the rolling upgrades failing I can see them failing also with the previous
patch that day - CASSANDRA-17014.
Please check [here|https://ci-cassandra.apache.org/job/Cassandra-3.0/204/].
for 3.0 and also failing in Jenkins for 3.11
[here|https://jenkins-cm4.apache.org/job/Cassandra-3.11/265/#showFailuresLink]
The tests were passing in 3.0 for CASSANDRA-16795
[here|https://ci-cassandra.apache.org/job/Cassandra-3.0/200/].
If it is not CASSANDRA-17014, then there are only two other option possible
after CASSANDRA-16795 -
CASSANDRA-16959 or CASSANDRA-14612.
Unfortunately, there is no more history in Jenkins and I can't run them locally
for some reason now to test. And with this I will move the discussion to
CASSANDRA-17140, just wanted to clarify.
was (Author: e.dimitrova):
I think also previous versions have failing upgrade tests. There is ticket
CASSANDRA-17140 and I was also bisecting today as I didn't know about [~bereng]
's findings until I read this one but I have reached to the same conclusion
that this Is where the failures started, same day. Jenkins lacks some runs
history for newer branches but looking into 3.0 now where we also have the
rolling upgrades failing I can see them failing also with the previous patch
that day - CASSANDRA-17014.
Please check [here|https://ci-cassandra.apache.org/job/Cassandra-3.0/204/].
for 3.0 and also failing in Jenkins for 3.11
[here|https://jenkins-cm4.apache.org/job/Cassandra-3.11/265/#showFailuresLink]
The tests were passing in 3.0 for CASSANDRA-16795
[here|https://ci-cassandra.apache.org/job/Cassandra-3.0/200/].
If it is not CASSANDRA-17014, then there are only two other option possible
after CASSANDRA-16795 -
CASSANDRA-16959 or CASSANDRA-14612.
Unfortunately, there is no more history in Jenkins and I can't run them locally
for some reason now to test. And with this I will move the discussion to
CASSANDRA-17140, just wanted to clarify.
> 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
> Components: Messaging/Client
> Reporter: Olivier Michallat
> Assignee: Alex Petrov
> Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2, 4.1
>
>
> {{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
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
