[
https://issues.apache.org/jira/browse/CASSANDRA-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14716905#comment-14716905
]
Ariel Weisberg commented on CASSANDRA-9738:
-------------------------------------------
How big is the realistic size range of key cache values?
The only thing that makes me uncomfortable right now is the buffer handling for
the serializing the key cache value in serializedSize(). Resizing in the loop
is 4k at a time and not doubling. I think it at least needs to double to manage
whatever the worst case is.
It seems to me like the right tack on failure is to allocate the correct size
buffer by calculating the size the old way or double (for lg(n)). Doubling is
fine if we really never expect sane data models to hit it. Doubling is not
going to be great for people to hit under real world conditions especially if
they have to do it several times.
It's tempting to ask to have 10189 expanded to be "make this stuff fast" and
then do it the old way in this change set, but I could be convinced if there
isn't a really bad corner case.
Also next time could you wait +1 to squash? I can't see your last few change
sets once you squash. I am guilty of this too and now I know how it feels.
> Migrate key-cache to be fully off-heap
> --------------------------------------
>
> Key: CASSANDRA-9738
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9738
> Project: Cassandra
> Issue Type: Sub-task
> Reporter: Robert Stupp
> Assignee: Robert Stupp
> Fix For: 3.0 beta 2
>
>
> Key cache still uses a concurrent map on-heap. This could go to off-heap and
> feels doable now after CASSANDRA-8099.
> Evaluation should be done in advance based on a POC to prove that pure
> off-heap counter cache buys a performance and/or gc-pressure improvement.
> In theory, elimination of on-heap management of the map should buy us some
> benefit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
