cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-13063) Too many instances of BigVersion
Date Wed, 21 Dec 2016 18:53:58 GMT


Aleksey Yeschenko commented on CASSANDRA-13063:

Even at one million instances, compared to all the memory consumed by Cassandra, this is a
complete non-issue.

But if you really feel so strongly about going ahead, at least don't introduce CHMs whenever
non necessary, like here. I'd prefer you just did nothing at all, but if you want to do something,
go with what Sylvain said, at least.

P.S. If CHM *was* a good idea here, all you need would be {{return versions.computeIfAbsent(version,

> Too many instances of BigVersion
> --------------------------------
>                 Key: CASSANDRA-13063
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Simon Zhou
>            Assignee: Simon Zhou
>            Priority: Minor
> When debugging with Cassandra 3.0.10 I found 70+ BigVersion objects on a new node after
. This was from a cluster created by CMM and had very little data. Since we create a new instance
of BigVersion for each SSTable, that would create too many objects, eg, when bootstrapping
new node in a cluster with many sstables.
> Looks like sstables can actually share the same BigVersion instance as long as they has
same version. What we can do is to create a object cache and only create new object if not
> {code}
> ConcurrentHashMap<String, BigVersion> versions = new ConcurrentHashMap<>();
> {code}
> May not be a big deal but a minor improvement.  [~tjake] what do you think?

This message was sent by Atlassian JIRA

View raw message