[ 
https://issues.apache.org/jira/browse/CASSANDRA-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284541#comment-13284541
 ] 

Jonathan Ellis commented on CASSANDRA-2116:
-------------------------------------------

I think you're probably right.  Ideally what I'd like is something like this:

- Code that knows what disk is involved throws an FSReadError/FSWriteError that 
*records the disk/volume in question*
- Notably this will not necessarily be the lowest-level code, which often just 
takes a DataInput or DataOutput interface.  We'll want to declare the checked 
IOException at that level to make sure we handle it higher up
- Our global uncaught exception handler can mark the disks in question bad 
(exactly where CASSANDRA-2118 looks to terminate things; could handle this over 
there to go with the existing division of code)
- As for the request that hit the exception in the first place, we just allow 
that to fail + timeout normally; little benefit to be had by complicating that 
further (which is the approach taken here and 2118; I just note it to be 
explicit)
                
> Separate out filesystem errors from generic IOErrors
> ----------------------------------------------------
>
>                 Key: CASSANDRA-2116
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2116
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Chris Goffinet
>            Priority: Minor
>             Fix For: 1.2
>
>         Attachments: 
> 0001-Separate-out-filesystem-errors-from-generic-IOErrors.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

        

Reply via email to