accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Turner (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-1654) Bug in encryption-at-rest causes periodic IOExceptions
Date Fri, 16 Aug 2013 15:19:47 GMT

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

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

bq. Unfortunately I cannot think of a good way to create a test around this.  

I suspected this, but was not sure.  So for release testing we probably need to run continuous
ingest w/ and w/o encryption inorder to catch bugs like this.  However this may be forgotten.
 Running random walk on a cluster may have caught this also.  Maybe random walk needs the
ability to generate a random config for Accumulo.  This would allow random walk to run with
encryption sometimes and sometimes without.  Actually I suppose this random config generator
could be use for continous ingest also.

bq. Is this something a system like FindBugs would have caught?

Seems possible.  I suppose if you are calling read() w/o checking how much was read, that
could be detected via static analysis.  If find bugs does not have this check, it probably
should.  


                
> 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

Mime
View raw message