[
https://issues.apache.org/jira/browse/CASSANDRA-19986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-19986:
----------------------------------------
Fix Version/s: 4.0.15
4.1.8
5.0.3
(was: 4.0.x)
(was: 4.1.x)
(was: 5.0.x)
Source Control Link:
https://github.com/apache/cassandra/commit/ff54fd5ffd03846326862951e2a6de9b52de01f6
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Prepared statements cache computation improvements
> --------------------------------------------------
>
> Key: CASSANDRA-19986
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19986
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
> Reporter: Berenguer Blasi
> Assignee: Berenguer Blasi
> Priority: Normal
> Fix For: 4.0.15, 4.1.8, 5.0.3, 5.1
>
> Attachments: screenshot-1.png
>
>
> Currently prepared statements size are computed twice which is duplicate
> effort:
> -
> [https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L672]
> -
> [https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L802]
> But we also get the side effect of that 'slow' computation locking the
> underlying ConcurrentHashMap. We've had nodes becoming unresponsively slow
> for hours with hundreds of threads in jstack all queued up behind
> {{computeIfAbsent}} operations on cache insertion/eviction collisions.
> Computing size only once and pulling that value instead of recomputing it on
> cache insertion was the solution
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
