[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14228575#comment-14228575
]
Benedict commented on CASSANDRA-7438:
-------------------------------------
bq. I am 100% sure
Never be 100% sure with concurrency, please :)
bq. test case again plz. I don't think this can happen too. I spend a lot of
time testing the exact scenario.
You have too much faith in tests. You are testing under ideal conditions - two
of the race conditions I highlighted will only rear their heads infrequently,
most likely when the system is under uncharacteristic load causing very choppy
scheduling. Analysis of the code is paramount. I will not produce a test case
as I do not have time, however I will give you an interleaving of events that
would trigger one of them.
Thread A is deleting an item, and is in LRUC.invalidate(), Thread B is looking
up the same item, in LRUC.get().
A: 187: map.remove()
B: 154 :map.get()
A: 191: queue.deleteFromQueue()
B: 158: queue.addToQueue()
In particular, addToQueue() sets the markAsDeleted flag to false, undoing the
prior work of deleteFromQueue.
bq. Thread is only signalled if they are not performing operation. I am lost.
It will generally not be performing an operation, because its work will be
faster than any of the producers can produce work in normal C* operation.
> Serializing Row cache alternative (Fully off heap)
> --------------------------------------------------
>
> Key: CASSANDRA-7438
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7438
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Environment: Linux
> Reporter: Vijay
> Assignee: Vijay
> Labels: performance
> Fix For: 3.0
>
> Attachments: 0001-CASSANDRA-7438.patch, tests.zip
>
>
> Currently SerializingCache is partially off heap, keys are still stored in
> JVM heap as BB,
> * There is a higher GC costs for a reasonably big cache.
> * Some users have used the row cache efficiently in production for better
> results, but this requires careful tunning.
> * Overhead in Memory for the cache entries are relatively high.
> So the proposal for this ticket is to move the LRU cache logic completely off
> heap and use JNI to interact with cache. We might want to ensure that the new
> implementation match the existing API's (ICache), and the implementation
> needs to have safe memory access, low overhead in memory and less memcpy's
> (As much as possible).
> We might also want to make this cache configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
