[
https://issues.apache.org/jira/browse/CASSANDRA-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607486#comment-17607486
]
Jaydeepkumar Chovatia edited comment on CASSANDRA-17248 at 9/27/22 6:38 PM:
----------------------------------------------------------------------------
[~ifesdjeen] I've created a patch (on 3.0 for now) that includes the following:
# It Fixes the potential root cause in which we should never ever prepare a
statement for non-fully qualified queries with null keyspace
# With this patch, collision for two keyspaces having the same schema should
never ever occur. Let's say in the worst scenario, it does happen, then it is a
bug on the Cassandra server we need to investigate. Cassandra should never
silently ignore it as it leads to a *{color:#de350b}disastrous{color}*
situation to be in. This patch throws an exception back to the user instead of
silently ignoring it.
# Additional stats that tell us prepared statement behavior, such as cache
used, empty prepared statements, etc.
# Last but not least, unit test cases that would cover collision scenarios.
The test cases added in this diff passed with 3.0.14 - fails with 3.0.26 (w/o
this patch) - but passed with this patch
Please find the 3.0 Patch here:
[https://github.com/jaydeepkumar1984/cassandra/pull/1/commits/37e60cac04df6c7042f4a83f50c046effc60ac04|https://github.com/apache/cassandra/pull/1872/commits/758bc4a89d7ca9d0bfe27e6f41000484724261bc]
Please review it and then I will create more patches for 3.11, 4.0, and trunk.
was (Author: chovatia.jayd...@gmail.com):
[~ifesdjeen] I've created a patch (on 3.0 for now) that includes the following:
# It Fixes the potential root cause in which we should never ever prepare a
statement for non-fully qualified queries with null keyspace
# With this patch, collision for two keyspaces having the same schema should
never ever occur. Let's say in the worst scenario, it does happen, then it is a
bug on the Cassandra server we need to investigate. Cassandra should never
silently ignore it as it leads to a *{color:#de350b}disastrous{color}*
situation to be in. This patch throws an exception back to the user instead of
silently ignoring it.
# Additional stats that tell us prepared statement behavior, such as cache
used, empty prepared statements, etc.
# Last but not least, unit test cases that would cover collision scenarios.
The test cases added in this diff passed with 3.0.14 - fails with 3.0.26 (w/o
this patch) - but passed with this patch
Please find the 3.0 Patch here:
[https://github.com/jaydeepkumar1984/cassandra/pull/1/commits/37e60cac04df6c7042f4a83f50c046effc60ac04]
Please review it and then I will create more patches for 3.11, 4.0, and trunk.
> 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
