Thank you all for your valuable comments and information.
-SC
> Date: Tue, 3 Sep 2013 12:01:59 -0400
> From: chris.burrou...@gmail.com
> To: user@cassandra.apache.org
> CC: fsareshw...@quantcast.com
> Subject: Re: row cache
>
> On 09/01/2013 03:06 PM, Faraaz Sareshwala wrote:
> > Yes, that is correct.
> >
> > The SerializingCacheProvider stores row cache contents off heap. I believe
> > you
> > need JNA enabled for this though. Someone please correct me if I am wrong
> > here.
> >
> > The ConcurrentLinkedHashCacheProvider stores row cache contents on the java
> > heap
> > itself.
> >
>
> Naming things is hard. Both caches are in memory and are backed by a
> ConcurrentLinkekHashMap. In the case of the SerializingCacheProvider
> the *values* are stored in off heap buffers. Both must store a half
> dozen or so objects (on heap) per entry
> (org.apache.cassandra.cache.RowCacheKey,
> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$WeightedValue,
> java.util.concurrent.ConcurrentHashMap$HashEntry, etc). It would
> probably be better to call this a "mixed-heap" rather than off-heap
> cache. You may find the number of entires you can hold without gc
> problems to be surprising low (relative to say memcached, or physical
> memory on modern hardware).
>
> Invalidating a column with SerializingCacheProvider invalidates the
> entire row while with ConcurrentLinkedHashCacheProvider it does not.
> SerializingCacheProvider does not require JNA.
>
> Both also use memory estimation of the size (of the values only) to
> determine the total number of entries retained. Estimating the size of
> the totally on-heap ConcurrentLinkedHashCacheProvider has historically
> been dicey since we switched from sizing in entries, and it has been
> removed in 2.0.0.
>
> As said elsewhere in this thread the utility of the row cache varies
> from "absolutely essential" to "source of numerous problems" depending
> on the specifics of the data model and request distribution.
>
>
