[
https://issues.apache.org/jira/browse/CASSANDRA-6283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905320#comment-13905320
]
Andreas Schnitzerling edited comment on CASSANDRA-6283 at 2/19/14 11:54 AM:
----------------------------------------------------------------------------
I think, not stopping java in general allows deleting, but stopping the
cassandra process which keeps file handles open. When I first studied the C*
code, I found it difficult to see, how filehandles are spread around in
different classes (?). Not easy, to keep the overview for me, but maybe its
because of not enough java experience compared to C++ where I had to care for
handles as well (file, memory). Later in C++, there were autopointers
(boost/TR1) with a finalizer-like approach, where memory was deleted
automatically (analog to closing files), when handle went out of scope or the
programmer "forgot" to free/close. I don't know about the linux' process
explorer, where filehandles are expected. But if I probably close every
filehandle after use (even only reading), does it matter, what's in this
process explorer, as long C* is able to delete? BTW if only a read process
don't close the file handle, it makes already sense for me to forbid to delete,
as long the os knows, the file is still used any way, except the user has to
kill or restart the process, where the handles automatically disappear, mostly
caused by problems. For me, it's a failure of the os as manager, to allow
delete a file, as long there are any filehandles on it. This strict permission
allows me as well, to detect failures in my program logic.
was (Author: andie78):
I think, not stopping java in general allows deleting, but stopping the
cassandra process which keeps file handles open. When I first studied the C*
code, I found it difficult to see, how filehandles are spread around in
different classes (?). Not easy, to keep the overview for me, but maybe its
because of not enough java experience compared to C++ where I had to care for
handles as well (file, memory). Later in C++, there were autopointers
(boost/TR1) with a finalizer-like approach, where memory was deleted
automatically (analog to closing files), when handle went out of scope or the
programmer "forgot" to free/close. I don't know about the linux' process
explorer, where filehandles are expected. But if I probably close every
filehandle after use (even only reading), does it matter, what's in this
process explorer, as long C* is able to delete? BTW if only a read process
don't close the file handle, it makes already sense to forbid to delete, as
long the os knows, the file is still used any way. For me, it's a failure of
the os as manager, to allow delete a file, as long there are any filehandles on
it. This strict permission allows me as well, to detect failures in my program
logic.
> 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)
