[CASSANDRA-17401] Race condition in QueryProcessor causes just prepared statement not to be in the prepared statements cache

• Type: Bug
• Status: Open
• Priority: Normal
• Resolution: Unresolved
• Component/s: Messaging/Client
• Bug Category: Correctness - Transient Incorrect Response
• Severity: Normal
• Complexity: Normal
• Discovered By: User Report
• Platform: All
• Assignee: Jaydeepkumar Chovatia
• Reporter: Ivan Senic

Authors

Jaydeepkumar Chovatia

Reviewers

Paulo Motta

• Created: 23/Feb/22 09:15
• Updated: 28/Feb/24 16:17

Description

The changes in the QueryProcessor#prepare 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.

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), 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.

Issue Links

• links to: GitHub Pull Request #3058