accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Turner (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-1654) Bug in encryption-at-rest causes periodic IOExceptions
Date Fri, 16 Aug 2013 13:56:50 GMT


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:
>             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:

View raw message