[
https://issues.apache.org/jira/browse/CASSANDRA-17401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Senic updated CASSANDRA-17401:
---
Description:
The changes in the
[QueryProcessor#prepare|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L575-L638]
method that were introduced in versions *4.0.2* and *3.11.12* can cause a race
condition between two threads trying to concurrently prepare the same
statement. This race condition can cause removing of a prepared statement from
the cache, after one of the threads has received the result of the prepare and
eventually uses MD5Digest to call
[QueryProcessor#getPrepared|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L212-L215].
The race condition looks like this:
* Thread1 enters _prepare_ method and resolves _safeToReturnCached_ as false
* Thread1 executes eviction of hashes
* Thread2 enters _prepare_ method and resolves _safeToReturnCached_ as false
* Thread1 prepares the statement and caches it
* Thread1 returns the result of the prepare
* Thread2 executes eviction of hashes
* Thread1 tries to execute the prepared statement with the received MD5Digest,
but statement is not in the cache as it was evicted by Thread2
I tried to reproduce this by using a Java driver, but hitting this case from a
client side is highly unlikely and I can not simulate the needed race
condition. However, we can easily reproduce this in Stargate (details
[here|https://github.com/stargate/stargate/pull/1647]), as it's closer to
QueryProcessor.
Reproducing this in a unit test is fairly easy. I am happy to showcase this if
needed.
Note that the issue can occur only when safeToReturnCached is resolved as
false.
was:
The changes in the
[QueryProcessor#prepare|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L575-L638]
method that were introduced in versions *4.0.2* and *3.11.12* can cause a race
condition between two threads trying to concurrently prepare the same
statement. This race condition can cause removing of a prepared statement from
the cache, after one of the threads has received the result of the prepare and
eventually uses MD5Digest to call
[QueryProcessor#getPrepared|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L212-L215].
The race condition looks like this:
* Thread1 enters _prepare_ method and resolves _safeToReturnCached_ as false
* Thread1 executes eviction of hashes
* Thread2 enters _prepare_ method and resolves _safeToReturnCached_ as false
* Thread1 prepares the statement and caches it
* Thread1 returns the result of the prepare
* Thread2 executes eviction of hashes
* Thread1 tries to execute the prepared statement with the received MD5Digest,
but statement is not in the cache as it was evicted by Thread2
I tried to reproduce this by using a Java driver, but hitting this case from a
client side is highly unlikely and I can not simulate the needed race
condition. However, we can easily reproduce this in Stargate (details
[here|https://github.com/stargate/stargate/pull/1647]), as it's closer to
QueryProcessor.
Reproducing this in a unit test is fairly easy. I am happy to showcase this if
needed.
Note that the issue can occur only when safeToReturnCached is resolved as
false.
> Race condition in QueryProcessor causes just prepared statement not to be in
> the prepared statements cache
> --
>
> Key: CASSANDRA-17401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17401
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ivan Senic
>Priority: Normal
>
> The changes in the
> [QueryProcessor#prepare|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L575-L638]
> method that were introduced in versions *4.0.2* and *3.11.12* can cause a
> race condition between two threads trying to concurrently prepare the same
> statement. This race condition can cause removing of a prepared statement
> from the cache, after one of the threads has received the result of the
> prepare and eventually uses MD5Digest to call
> [QueryProcessor#getPrepared|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L212-L215].
> The race condition looks like this:
> * Thread1 enters _prepare_ method and resolves _safeToReturnCached_ as false
> * Thread1 executes eviction of hashes
> * Thread2 enters _prepare_ method and resolves _safeToReturnCached_ as false
> * Thread1 prepares the statement and
