cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-414) remove sstableLock
Date Fri, 04 Sep 2009 21:34:57 GMT


Jonathan Ellis commented on CASSANDRA-414:

when compaction completes it modifies CFS.sstables_ as follows:

    - sstables_.put(new compacted sstable)
    - remove the source sstables & delete their file on disk

now, NonBlockingHashMap guarantees that "Iterators and Enumerations return elements reflecting
the state of the hash table at some point at or since the creation of the iterator/enumeration."
 BUT this has no effect on other parts of the system, particularly the delete!

so the fundamental problem exhibeted by the unit tests is this:

    - thread A starts iterating over sstables_
    - compaction thread finishes and does its thing.  now some of the files A needs to see
a consistent view of the data are gone: the set of sstables being iterated over was in fact
consistent but because we're violating encapsulation by doing the delete and remove separately,
we can get incorrect results.

I think the simplest solution is to use pseudo-finalizers to do the actual file delete once
no references to the owning SSTableReader exist anymore.  These can be done using

> remove sstableLock
> ------------------
>                 Key: CASSANDRA-414
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>             Fix For: 0.5
>         Attachments: 0001-CASSANDRA-414-combine-addToList-and-storeLocation-ren.txt,
0001-CASSANDRA-414-combine-addToList-and-storeLocation-ren.txt, 0002-remove-sstableLock.-re-order-a-few-ops-so-that-we-can.txt,

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message