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

Terje Marthinussen commented on CASSANDRA-2521:
-----------------------------------------------

I have not found any further major issues here, but I think there is still 
situations where files are deleted late but they do seem to go away.

Not sure if we are missing something in terms of reference counting and GC 
delete it eventually or it is just a delayed free or delete for some reason, 
but it does not happen too often.

Will see try to add some debug logging and see what I find.

I was looking at the code though and I am wondering about one segment. I have 
not had time to actually test this, but in submitUserDefined() there is a 
finally statement removing References for "sstables" but I could not 
immediately see where there are References acquired for all the sstables that 
needs to be freed there?

I am sure it's just me missing something, but anyway...


> Move away from Phantom References for Compaction/Memtable
> ---------------------------------------------------------
>
>                 Key: CASSANDRA-2521
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2521
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Chris Goffinet
>            Assignee: Sylvain Lebresne
>             Fix For: 1.0
>
>         Attachments: 
> 0001-Use-reference-counting-to-decide-when-a-sstable-can-.patch, 
> 0001-Use-reference-counting-to-decide-when-a-sstable-can-v2.patch, 
> 0002-Force-unmapping-files-before-deletion-v2.patch, 2521-v3.txt, 2521-v4.txt
>
>
> http://wiki.apache.org/cassandra/MemtableSSTable
> Let's move to using reference counting instead of relying on GC to be called 
> in StorageService.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to