[
https://issues.apache.org/jira/browse/CASSANDRA-6283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13907134#comment-13907134
]
Joshua McKenzie commented on CASSANDRA-6283:
--------------------------------------------
It's possible the two are the same underlying problem. We use hardlinks both
during the snapshot process and during flushing of memtables - I'll have to
think for a bit on the best way to test that theory out since your stack shows
us the LEAK being cleaned up but doesn't (and can't) give us any indication of
who it is that might still hold the reference to the handle.
As for the tmp folder and file growth - the hard links won't be kept open in
the FD table for java so we shouldn't run the risk of an FD limit, however the
drive space would still be used until the process was shut down. I was
thinking the addition of a periodic "delete tmp/moved_hard_links/*" type pass
should help mitigate that, though it smells hacky to me.
Another option would be copying files instead of hard linking them during these
operations on Windows only, but I think the performance ramifications of that
make that option unworkable.
> Windows 7 data files keept open / can't be deleted after compaction.
> --------------------------------------------------------------------
>
> Key: CASSANDRA-6283
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6283
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Windows 7 (32) / Java 1.7.0.45
> Reporter: Andreas Schnitzerling
> Assignee: Joshua McKenzie
> Labels: compaction
> Fix For: 2.0.6
>
> Attachments: leakdetect.patch, screenshot-1.jpg, system.log
>
>
> Files cannot be deleted, patch CASSANDRA-5383 (Win7 deleting problem) doesn't
> help on Win-7 on Cassandra 2.0.2. Even 2.1 Snapshot is not running. The cause
> is: Opened file handles seem to be lost and not closed properly. Win 7
> blames, that another process is still using the file (but its obviously
> cassandra). Only restart of the server makes the files deleted. But after
> heavy using (changes) of tables, there are about 24K files in the data folder
> (instead of 35 after every restart) and Cassandra crashes. I experiminted and
> I found out, that a finalizer fixes the problem. So after GC the files will
> be deleted (not optimal, but working fine). It runs now 2 days continously
> without problem. Possible fix/test:
> I wrote the following finalizer at the end of class
> org.apache.cassandra.io.util.RandomAccessReader:
> {code:title=RandomAccessReader.java|borderStyle=solid}
> @Override
> protected void finalize() throws Throwable {
> deallocate();
> super.finalize();
> }
> {code}
> Can somebody test / develop / patch it? Thx.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)