Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Tue, 4 Oct 2016 19:54:20 +0000 (UTC)
From: "Josh Elser (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.13009347.1475527654000.734759.1475610860578@Atlassian.JIRA>
In-Reply-To: <JIRA.13009347.1475527654000@Atlassian.JIRA>
References: <JIRA.13009347.1475527654000@Atlassian.JIRA> <JIRA.13009347.1475527654436@arcas>
Subject: [jira] [Commented] (ACCUMULO-4483) NegativeArraySizeException from
 scan thread right after minor compaction
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 04 Oct 2016 19:54:22 -0000


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

Josh Elser commented on ACCUMULO-4483:
--------------------------------------

bq.  Not sure. The issue arose on multiple clusters as soon as I upgraded to 1.8.0. We run continuous ingest for our tests, but are we continuously scanning during the ingest?

If the batchwalkers, walkers, and/or scanners are started, yes. 

> NegativeArraySizeException from scan thread right after minor compaction
> ------------------------------------------------------------------------
>
>                 Key: ACCUMULO-4483
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4483
>             Project: Accumulo
>          Issue Type: Bug
>          Components: tserver
>    Affects Versions: 1.8.0
>         Environment: Accumulo 1.8.0
> Java 1.8.0_72
>            Reporter: Dave Marion
>            Assignee: Dave Marion
>            Priority: Blocker
>             Fix For: 1.8.1, 2.0.0
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> I have been getting NegativeArraySizeExceptions after upgrading to Accumulo 1.8.0. I have tracked it down to 2 or more concurrent scans on a tablet that has just undergone minor compaction. The minor compaction thread writes the in-memory map to a local temporary rfile and tries to switch the current iterators to use it instead of the native map. The iterator code in the scan thread may also switch itself to use the local temporary rfile it if notices it before the minor compaction threads performs the switch. This all works up to this point. Shortly after the switch one of the iterator threads will get a NegativeArraySizeException from:
> SourceSwitchingIterator.seek() -> SourceSwitchingIterator.readNext() -> MemKeyConversionIterator.seek() -> MemKeyConversionIterator.getTopKeyValue() ->MemValue.decode(). I added a bunch of logging to find that the length of the byte array passed to MemValue.decode is zero.


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