Thank Rob, I trigger user defined compaction to big sstables (big as in the size per sstable reach more than 50GB, some 100GB). Occasionally, after user defined compaction, I see some sstables remain, even after 12 hours elapsed.
You mentioned a thread, could you tell what threads are those or perhaps highlight in the code? Jason On Sat, Feb 14, 2015 at 3:58 AM, Robert Coli <rc...@eventbrite.com> wrote: > On Fri, Feb 13, 2015 at 1:35 AM, Jason Wee <peich...@gmail.com> wrote: > >> Pre cassandra 1.0, after sstables are compacted, the old sstables will be >> remain until the first gc kick in. For cassandra 1.0, the sstables will be >> remove after compaction is done. Will it be possible the old sstables >> remains due to whatever reasons (e.g. read referencing)? >> > > If I understand your question properly, the answer is "no" or "not for > longer than the duration of a running thread." > > If compaction is working properly in a > post-needs-the-java-GC-to-delete-files version of Cassandra the input files > should be deleted ASAP. If a thread is actively accessing that file, I > would imagine it blocks for that long, but that's not likely to be very > long. > > =Rob > >
