cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-2116) Separate out filesystem errors from generic IOErrors
Date Sat, 21 Jul 2012 03:29:36 GMT

    [ 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

        

Mime
View raw message