[
https://issues.apache.org/jira/browse/CASSANDRA-8499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14255596#comment-14255596
]
Marcus Eriksson commented on CASSANDRA-8499:
--------------------------------------------
In general LGTM, but at least for the 2.0 patch I think we should mimic current
behavior as much as possible (ie, in SSTableWriter.abort(), we used
closeQuietly which only logs an error message if we fail closing, now we throw
an FSWriteError).
Since we always* propagate the exception that caused abort() to be called,
maybe it is better to always just log the exceptions in abort() and let the
cause of abort() be thrown all the way out? (*we should propagate the cause in
doAntiCompaction as well)
> Ensure SSTableWriter cleans up properly after failure
> -----------------------------------------------------
>
> Key: CASSANDRA-8499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8499
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Fix For: 2.0.12
>
> Attachments: 8499-20.txt, 8499-21.txt
>
>
> In 2.0 we do not free a bloom filter, in 2.1 we do not free a small piece of
> offheap memory for writing compression metadata. In both we attempt to flush
> the BF despite having encountered an exception, making the exception slow to
> propagate.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
