[ https://issues.apache.org/jira/browse/ACCUMULO-4483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dave Marion reassigned ACCUMULO-4483: ------------------------------------- Assignee: Dave Marion > 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)