[
https://issues.apache.org/jira/browse/ACCUMULO-4483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15543390#comment-15543390
]
Dave Marion commented on ACCUMULO-4483:
---------------------------------------
I should note that I did not see this in 1.7. This might also be related to
ACCUMULO-4391.
> 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
> Priority: Critical
>
> 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)
