cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Eriksson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8499) Ensure SSTableWriter cleans up properly after failure
Date Mon, 22 Dec 2014 09:55:13 GMT

    [ 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)

Mime
View raw message