You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "Keith Turner (JIRA)" <ji...@apache.org> on 2013/08/16 15:56:50 UTC

[jira] [Commented] (ACCUMULO-1654) Bug in encryption-at-rest causes periodic IOExceptions

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

Keith Turner commented on ACCUMULO-1654:
----------------------------------------

Nice catch.  Would it be possible to create a test that recreates this issue inorder to prevent regressions? Is there a sequence of operations (compactions, scans, splits) that will reproduce this issue?

Do you think this "secret key handling strategy" deserves its own ticket?  I'm thinking about the 1.6.0 release notes and wondering if it deserves its own line.  It seems like this is a performance bug fix that does not change the encryption API or configuration?  If its not a feature, its probably ok to lump it in with the other bug fix because.  Bug fixes against unreleased features eventually just add noise to the release notes. 


                
> Bug in encryption-at-rest causes periodic IOExceptions
> ------------------------------------------------------
>
>                 Key: ACCUMULO-1654
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1654
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: tserver
>            Reporter: Michael Allen
>             Fix For: 1.6.0
>
>         Attachments: 0001-Fixed-a-bug-where-keys-and-IVs-from-encrypted-files-.patch
>
>
> During longevity testing of the encryption-at-rest version of Accumulo, we would occasionally see IOExceptions that took the form of Zlib throwing an "incorrect header check" exception.  These exceptions occurred only after a few hours of testing, during minor and major compaction of various RFiles.  Downloading and examining the RFiles in question showed no obvious deformities within the RFile structure.  
> Some careful debugging later, the crux of the problem turned out to be some calls to read() when readFully() should have been used.  
> Patch coming forthwith.  Also included in this patch is another secret key handling strategy that caches the secret key from HDFS when first read.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira