[jira] [Issue Comment Edited] (CASSANDRA-3862) RowCache misses Updates

["Jonathan Ellis (Issue Comment Edited) (JIRA)" <ji...@apache.org>]

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

Jonathan Ellis edited comment on CASSANDRA-3862 at 2/24/12 11:19 PM:
---------------------------------------------------------------------

v7 attached.

bq. Since we don't add stuffs to the sentinel, it has no reason to be a subclass of ColumnFamily

True, but when I tried this I ended up with a LOT of casting cache values to CF.  I think it might be the lesser of evils the way it is.

bq. the counter special case is not needed anymore

Updated.

bq. if we fail to replace the sentinel, I think we should still better return the data rather than looping and re-reading

Makes sense, updated.

bq. Is it really an improvement to use UUIDs (over an AtomicLong)? 

I'd rather have the reduced contention on instantiation than the 8 bytes of space (during the sentinel lifetime -- this goes away once the sentinel is replaced by the data CF).
                
      was (Author: jbellis):
    v7 attached.

bq. Since we don't add stuffs to the sentinel, it has no reason to be a subclass of ColumnFamily

True, but when I tried this I ended up with a LOT of casting cache values to CF.  I think it might be the lesser of evils the way it is.

bq. the counter special case is not needed anymore

Updated.

bq. if we fail to replace the sentinel, I think we should still better return the data rather than looping and re-reading

Makes sense, updated.

bq. Is it really an improvement to use UUIDs (over an AtomicLong)? 

I'd rather have the reduced contention on instantiation than the 4 bytes of space (during the sentinel lifetime -- this goes away once the sentinel is replaced by the data CF).
                  
> 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-7.txt, 3862-cleanup.txt, 3862-v2.patch, 3862-v4.patch, 3862-v5.txt, 3862-v6.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