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 15:19:47 GMT


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

> 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