cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3862) RowCache misses Updates
Date Thu, 23 Feb 2012 09:11:49 GMT

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

Sylvain Lebresne commented on CASSANDRA-3862:
---------------------------------------------

I don't think v5 works. All sentinels are empty CF, so all sentinels will be equal (in SerializingCache.contentsEqual()).
Which means we can have the following sequence of actions:
* a read r1 comes, the cache is empty, it sets sentinel s1 and start reading from disk
* a write w comes and invalidate s1.
* a read r2 comes, the cache is (now) empty, it sets sentinel s2 and start reading from disk
* r1 finish reading from disk having missed w. It'll do the replace, but since all sentinel
are equals this will succeed (even though the current sentinel is the one of the second read)
and we'll end up having missed w.

That's the reason of the sentinel IDs of v4.
                
> RowCache misses Updates
> -----------------------
>
>                 Key: CASSANDRA-3862
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3862
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.6
>            Reporter: Daniel Doubleday
>            Assignee: Sylvain Lebresne
>             Fix For: 1.1.0
>
>         Attachments: 3862-cleanup.txt, 3862-v2.patch, 3862-v4.patch, 3862-v5.txt, 3862.patch,
3862_v3.patch, include_memtables_in_rowcache_read.patch
>
>
> While performing stress tests to find any race problems for CASSANDRA-2864 I guess I
(re-)found one for the standard on-heap row cache.
> During my stress test I hava lots of threads running with some of them only reading other
writing and re-reading the value.
> This seems to happen:
> - Reader tries to read row A for the first time doing a getTopLevelColumns
> - Row A which is not in the cache yet is updated by Writer. The row is not eagerly read
during write (because we want fast writes) so the writer cannot perform a cache update
> - Reader puts the row in the cache which is now missing the update
> I already asked this some time ago on the mailing list but unfortunately didn't dig after
I got no answer since I assumed that I just missed something. In a way I still do but haven't
found any locking mechanism that makes sure that this should not happen.
> The problem can be reproduced with every run of my stress test. When I restart the server
the expected column is there. It's just missing from the cache.
> To test I have created a patch that merges memtables with the row cache. With the patch
the problem is gone.
> I can also reproduce in 0.8. Haven't checked 1.1 but I haven't found any relevant change
their either so I assume the same aplies there.

--
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