[
https://issues.apache.org/jira/browse/CASSANDRA-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419731#comment-13419731
]
Jonathan Ellis commented on CASSANDRA-2116:
-------------------------------------------
DD.createAllDirectories will stop trying to create as soon as the first
directory fails, so it's not going to be appropriate for generic FSWriteError
handling. Suggest logging an error and explicitly shutting down instead.
(This should only be called on startup.)
Looks like we should drop the "throws IOException" declaration from
applyIndexUpdates (and have that chain throw FSWE as needed).
BatchCommitLogExecutorService.processWithSyncBatch should throw FSWE instead of
RTE.
CommitLogSegment.sync should turn IOE into FSWE. Rest of sync heirarchy won't
need throws declaration.
Note for CASSANDRA-2118: will need to unwrap exceptions looking for FSWE since
CLES/PCLES can wrap in ExecutionException. (Others might as well. Easier to
do unwrap check in 2118 than to audit all possible executors.) On the other
hand, this makes trying to catch the error before it hits the exception hook
more of a pain, as in the next item...
CollationController needs to retain its try/catch, since we want to allow the
read to succeed, even if the defragmenting write fails. Since it could error
w/ either FSWE or EE (from the commitlog add), probably need to catch generic
Exception. For 2118 we can add some way to submit this to the disk blacklister
without re-throwing.
Looks like it would be worth adding a constructor for FSRW taking a Descriptor.
SSTR.createLinks should throw FSWE.
Methods called by SSTW constructor should throw FSWE.
SSTW methods should throw FSWE. (callers of append will want to catch +
re-throw after cleanup.)
TruncateVerbHandler (and anyone else) shouldn't swallow potential FSWE by
logging, need to rethrow. (FBUtilities.unchecked is handy in such cases.)
I agree with your use of AssertionError in LCR. Would prefer to use RTE in
SSTableReader though, since we do some tricky reference counting around that
and I wouldn't want to ignore problems there b/c someone turned off assertions.
(Surprisingly common...)
SSTII should throw IOException when it doesn't know what DataInput is. Callers
can transform to FSRE. (Other constructors, or in the last case,
IncomingStreamReader.)
Corrupt sstables (sstablescanner + others?) shouldn't be turned into FSRE,
since it's usually bad memory or a bug and not the disk's fault.
FileUtils should throw FSWE.
BTW: congratulations on getting import ordering (almost) correct on the first
try. The only thing missing is, com.google.common goes above org.slf4j instead
of being lumped in with "everything else."
> Separate out filesystem errors from generic IOErrors
> ----------------------------------------------------
>
> Key: CASSANDRA-2116
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2116
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Chris Goffinet
> Assignee: Aleksey Yeschenko
> Fix For: 1.2
>
> Attachments:
> 0001-Issue-2116-Replace-some-IOErrors-with-more-informati.patch,
> 0001-Separate-out-filesystem-errors-from-generic-IOErrors.patch,
> CASSANDRA-2116-v3.patch
>
>
> We throw IOErrors everywhere today in the codebase. We should separate out
> specific errors such as (reading, writing) from filesystem into FSReadError
> and FSWriteError. This makes it possible in the next ticket to allow certain
> failure modes (kill the server if reads or writes fail to disk).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
