accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Marion (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-4483) NegativeArraySizeException from scan thread right after minor compaction
Date Tue, 04 Oct 2016 19:02:20 GMT


Dave Marion commented on ACCUMULO-4483:

bq. The Value.set() doesn't appear to have been modified in Keith's commit though.

 The old code called Value.set() on the input object and didn't return anything. The new code
called Value.set() on the input object and returned a new MemValue. The calling code had been
changed to use the return value, and I'm assuming reuse the input object.

bq.  Curious that we didn't uncover this in any testing for 1.8.0. This would be good to understand
why (apparently?) our testing was insufficient to catch this.

 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?

> NegativeArraySizeException from scan thread right after minor compaction
> ------------------------------------------------------------------------
>                 Key: ACCUMULO-4483
>                 URL:
>             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
>            Priority: Blocker
>             Fix For: 1.8.1
>          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
> -> SourceSwitchingIterator.readNext() ->
-> 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

View raw message