[
https://issues.apache.org/jira/browse/ACCUMULO-4483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Marion resolved ACCUMULO-4483.
-----------------------------------
Resolution: Fixed
> 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
> Labels: hackathon2016
> Fix For: 1.8.1, 2.0.0
>
> Time Spent: 0.5h
> 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)
