cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vijay (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (CASSANDRA-4150) Looks like Maximum amount of cache available in 1.1 is 2 GB
Date Sun, 15 Apr 2012 00:07:19 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-4150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254190#comment-13254190
] 

Vijay edited comment on CASSANDRA-4150 at 4/15/12 12:07 AM:
------------------------------------------------------------

For the records the comments from issue in CLHM library:
{quote}
I think a long capacity is fine, but I'm not actively working on a next release to roll this
into soon. If this is critical than it could be a patch release. You are of course welcome
to fork if neither of those options are okay.

I helped my former colleagues at Google with Guava's CacheBuilder (formerly MapMaker), which
could be considered the successor to this project. There the maximum weight is a long.
{quote}

IRC: Guava doesnt support descendingKeySetWithLimit
Possibly fork the CLHM code into Cassandra code base or drop the hotkey's method and use guava
(Thats the only limitation which i see for now).
                
      was (Author: vijay2win@yahoo.com):
    For the records the comments from issue in CLHM library:
{quote}
I think a long capacity is fine, but I'm not actively working on a next release to roll this
into soon. If this is critical than it could be a patch release. You are of course welcome
to fork if neither of those options are okay.

I helped my former colleagues at Google with Guava's CacheBuilder (formerly MapMaker), which
could be considered the successor to this project. There the maximum weight is a long.
{quote}

IRC: Guava doesnt support descendingKeySetWithLimit

Looks like the minimum overhead serializing a ColumnFamily is 22 bytes:

{code}
// sentinal
out.writeBoolean(cf instanceof RowCacheSentinel);

// CF exist or not
dos.writeBoolean(true);
// CFID
dos.writeInt(columnFamily.id());

// CF Info
dos.writeInt(columnFamily.getLocalDeletionTime());
dos.writeLong(columnFamily.getMarkedForDeleteAt());

// column count
dos.writeInt(count);

1+1+4+4+8+4 = 22
{code}

So for this ticket, we can divide set the maximumWeightedCapacity as capacity/22 which will
allow us to go up-to 44 GB in 1.1 and we can work through the alternative in another ticket
for 1.2? Possibly fork the CLHM code into Cassandra code base or drop the hotkey's method
and use guava (Thats the only limitation which i see for now).
                  
> Looks like Maximum amount of cache available in 1.1 is 2 GB
> -----------------------------------------------------------
>
>                 Key: CASSANDRA-4150
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4150
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.1.0
>            Reporter: Vijay
>            Assignee: Vijay
>
> The problem is that capacity is a Integer which can maximum hold 2 GB,
> I will post a fix to CLHM in the mean time we might want to remove the maximumWeightedCapacity
code path (atleast for Serializing cache) and implement it in our code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message