cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Jirsa (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-14060) Separate CorruptSSTableException and FSError handling policies
Date Sat, 02 Dec 2017 23:23:00 GMT


Jeff Jirsa commented on CASSANDRA-14060:

I think what you're proposing sounds reasonable, but before I actually review, I want to look
at some of the history to remember how we got to this point.

Linking some topics for background:


[~iamaleksey] and [~kohlisankalp] - you two were involved in some of the earlier work. Does
this seem like we need a new policy here? 

[~jay.zhuang] - when you say most of your corrupt sstables aren't disk issues - to what do
you attribute them?

> Separate CorruptSSTableException and FSError handling policies
> --------------------------------------------------------------
>                 Key: CASSANDRA-14060
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Configuration
>            Reporter: Jay Zhuang
>            Assignee: Jay Zhuang
>            Priority: Minor
> Currently, if [{{disk_failure_policy}}|]
is set to {{stop}} (default), StorageService will shutdown for {{FSError}}, but not {{CorruptSSTableException}}
> But when we use policy: {{die}}, it has different behave, JVM will be killed for both
{{FSError}} and {{CorruptSSTableException}} [|]:
> ||{{disk_failure_policy}}|| hit {{FSError}} Exception || hit {{CorruptSSTableException}}
> |{{stop}}| (/) stop | (x) not stop |
> |{{die}}| (/) die | (/) die |
> We saw {{CorruptSSTableException}} from time to time in our production, but mostly it's
*not* because of a disk issue. So I would suggest having a separate policy for CorruptSSTable.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message