[
https://issues.apache.org/jira/browse/CASSANDRA-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14587250#comment-14587250
]
Benedict commented on CASSANDRA-9379:
-------------------------------------
For 3.0, I think we should introduce the data structure I linked above, for use
in managing Ref states. While CASSANDRA-9549 will be fixed by CLDeque, this
data structure still has O(N) modification time. Generally this is fine, but if
we have buggy / pathological behaviour again, it would be comforting to know
that no operation is slowed down by this. Since the code already exists, and
has pretty thorough accompanying test coverage, the labour involved should be
minimal.
What would be the preferred way to do this: bring in tree, or publish my
artefacts to maven?
> Use a collection supporting more efficient removal in Ref.GlobalState
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-9379
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9379
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Priority: Minor
>
> Ref is intended only to be used in places where there are very few Ref
> instances against a given object extant at any moment, so this collection
> does not need to be performant. But to avoid performance regressions, such as
> accidentally introduced in CASSANDRA-8897 (but avoidable via the scaling back
> of Ref use, since no longer necessary), we could use a collection that
> supports more efficient removal.
> I would prefer, however, not to use either of CHM or NBHM, since both are
> heavyweight objects, wasting a lot of heap; the former is also blocking, and
> the latter could be problematic for this kind of workload, since it can leave
> references present in the map after a deletion. The most suitable structure
> is the one I blogged about
> [here|http://belliottsmith.com/eventual-consistency-concurrent-data-structures/]
> and have on github
> [here|https://github.com/belliottsmith/bes-utils/blob/master/src/bes/concurrent/collections/SimpleCollection.java],
> since it offers lock-free append and wait-free removal, and ensures space
> utilization is as low as possible.
> Thoughts/opinions?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
