[
https://issues.apache.org/jira/browse/CASSANDRA-19986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17892386#comment-17892386
]
Stefan Miklosovic edited comment on CASSANDRA-19986 at 10/24/24 8:17 AM:
-------------------------------------------------------------------------
Two small nits and we are good to go. Could you please prepare remaining
branches with builds? Otherwise +1.
was (Author: smiklosovic):
One small nit and we are good to go. Could you please prepare remaining
branches with builds? Otherwise +1.
> 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.x, 4.1.x, 5.0.x, 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]
