[jira] [Commented] (CASSANDRA-2411) log why a SSTable is being deleted

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

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

Jonathan Ellis commented on CASSANDRA-2411:
-------------------------------------------

Maybe logging this at info at all is a mistake; it feels like we're leaking too much of the implementation out.  Should we change it to .debug as well as adding an explanation?

> log why a SSTable is being deleted
> ----------------------------------
>
>                 Key: CASSANDRA-2411
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2411
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 0.7.4
>            Reporter: Robert Coli
>            Priority: Minor
>
> ./src/java/org/apache/cassandra/io/sstable/SSTable.java: 147
> Has "        logger.info("Deleted " + desc); ".
> This combined with the JVM not being able to delete files until a GC has run means that restarting a node usually prompts a flood of log messages like :
> "Deleted /mnt/var/cassandra/data/Digg/UserActivity-10658-Data.db"
> I believe that I am not the only operator who reads a log upon restart that says "I deleted your data files" and becomes concerned.
> Now, personally, I have read the code and understand the conditions under which these files are deleted and so no longer get frightened. For new operators and people who may feel less comfortable reading the code, specifying WHY the file has been deleted ("Deleted <filename> because it was obsolete and marked for deletion as a result of compaction.") seems likely to reduce blood pressure and operator stress levels. :)

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