Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Mon, 12 Sep 2016 21:45:21 +0000 (UTC)
From: "Christopher Tubbs (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12992693.1469560317000.552961.1473716721672@Atlassian.JIRA>
In-Reply-To: <JIRA.12992693.1469560317000@Atlassian.JIRA>
References: <JIRA.12992693.1469560317000@Atlassian.JIRA> <JIRA.12992693.1469560317058@arcas>
Subject: [jira] [Resolved] (ACCUMULO-4391) Source deepcopies cannot be used
 safely in separate threads in tserver
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 12 Sep 2016 22:16:26 -0000


     [ https://issues.apache.org/jira/browse/ACCUMULO-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christopher Tubbs resolved ACCUMULO-4391.
-----------------------------------------
    Resolution: Fixed

Closing this. I created ACCUMULO-4455 for more tests. Please comment on or amend that issue to suggest specific test cases which could/should be added, so folks don't have to mine them from this discussion or the PR. Thanks :)

> Source deepcopies cannot be used safely in separate threads in tserver
> ----------------------------------------------------------------------
>
>                 Key: ACCUMULO-4391
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4391
>             Project: Accumulo
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.6.5
>            Reporter: Ivan Bella
>            Assignee: Ivan Bella
>             Fix For: 1.6.6, 1.7.3, 1.8.1, 2.0.0
>
>   Original Estimate: 24h
>          Time Spent: 16h 50m
>  Remaining Estimate: 7h 10m
>
> We have iterators that create deep copies of the source and use them in separate threads.  As it turns out this is not safe and we end up with many exceptions, mostly down in the ZlibDecompressor library.  Curiously if you turn on the data cache for the table being scanned then the errors disappear.
> After much hunting it turns out that the real bug is in the BoundedRangeFileInputStream.  The read() method therein appropriately synchronizes on the underlying FSDataInputStream, however the available() method does not.  Adding similar synchronization on that stream fixes the issues.  On a side note, the available() call is only invoked within the hadoop CompressionInputStream for use in the getPos() call.  That call does not appear to actually be used at least in this context.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)