[
https://issues.apache.org/jira/browse/CASSANDRA-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605998#comment-17605998
]
Jaydeepkumar Chovatia commented on CASSANDRA-17248:
---------------------------------------------------
[~ifesdjeen], I think this fix does not solve the regression as there is still
a regression when we are upgrading from the pre-3.0.26 version.
# For example, there are three Cassandra nodes, N1, N2, and N3 running a
version before 3.0.26
# There are two keyspaces k1 and k2, which has the exact same table schema in
them. Say k1.t1 schema = k2.t1 schema
# Application behavior with before 3.0.26 doing the following with prepared
statement:
{code:java}
Application1 (Contacting the N1):
a. gocql.Execute("Use K1")
b. PreparedStatement ps = gocql.Prepare("SELECT * FROM T1")
c. Print(ps.preparedID) // prints ID1{code}
{code:java}
Application2 (Contacting the N1):
a. gocql.Execute("Use K2")
b. PreparedStatement ps = gocql.Prepare("SELECT * FROM T1")
c. Print(ps.preparedID) // prints ID2{code}
# Now we upgrade N1 from 3.0.14 --> 3.0.26 (which has this fix) and yet N2, N3
are on pre 3.0.26 versions
*
{code:java}
Application1 (Contacting the N1):
a. gocql.Execute("Use K1")
b. PreparedStatement ps = gocql.Prepare("SELECT * FROM T1")
c. Print(ps.preparedID) // prints ID1{code}
{code:java}
Application2 (Contacting the N1):
a. gocql.Execute("Use K2")
b. PreparedStatement ps = gocql.Prepare("SELECT * FROM T1")
c. Print(ps.preparedID) // prints ID1{code}
If we look at the expected output after step3.a ({_}ID1{_}) and 3.b ({_}ID2{_})
then it does not match with the expected output after step4.a ({_}ID1{_}) and
step4.b ({_}*{color:#FF0000}ID1{color}*{_})
And I believe this regression is because while we are upgrading the flag
"{_}newPreparedStatementBehaviour"{_} will be "{_}false{_}," so we exclude the
keyspace names in the hash calculation; hence two same non-qualified query for
a different keyspace would have the same hash, which is
*{color:#FF0000}incorrect behavior with 3.0.26{color:#172b4d},{color}{color}*
{color:#FF0000}{color:#172b4d}and that brings unexpected behavior such as the
query for _K1_ might be served by _K2_ on the server side or vice
versa{color}{color}{color:#172b4d} {color}
The following code line from this fix is the issue.
{code:java}
ResultMessage.Prepared nonQualifiedWithoutKeyspace =
storePreparedStatement(queryString, null, prepared, forThrift);
if (!newPreparedStatementBehaviour)
return nonQualifiedWithoutKeyspace;
return nonQualifiedWithKeyspace;{code}
However, pre 3.0.26, we used to always consider keyspace in the calculation so
hash ID would never collide for the same non-qualified query.
{code:java}
ResultMessage.Prepared existing = getStoredPreparedStatement(queryString,
clientState.getRawKeyspace(), forThrift)
if (existing != null)
return existing; {code}
Could you please validate the above theory?
Jaydeep
> Fix Prepared Statements behaviours after 15252
> ----------------------------------------------
>
> Key: CASSANDRA-17248
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17248
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
> Reporter: Alex Petrov
> Assignee: Alex Petrov
> Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2
>
>
> [CASSANDRA-15252] has fixed an important issue: unwanted hash changes when
> preparing fully qualified prepared statements which was causing
> cluster-killing re-prepare loops. However, the fix introduced a regression:
> non-qualified statements can get prepared against one keyspace but then
> executed on another under some circumstances. This patch reconciles all
> behaviours.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
