Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Fri, 16 Aug 2013 14:50:48 +0000 (UTC)
From: "Adam Fuchs (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12663912.1376597799714.80586.1376664648064@arcas>
In-Reply-To: <JIRA.12663912.1376597799714@arcas>
References: <JIRA.12663912.1376597799714@arcas>
Subject: [jira] [Commented] (ACCUMULO-1654) Bug in encryption-at-rest causes
 periodic IOExceptions
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Adam Fuchs commented on ACCUMULO-1654:
--------------------------------------

I think what you would have to do to deterministicly replicate this is mock
up a file system that just gives one byte at a time. That could be done as
a simple wrapper that is inserted in some of the existing unit tests. Might
be worth it if it is that easy, but I could go either way.

Is this something a system like FindBugs would have caught?


> 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