[jira] [Resolved] (ACCUMULO-4713) IteratorUtil.minimizeEndKeyTimestamp() and IteratorUtil.maximizeStartKeyTimestamp() may not set correct ranges

["Michael Wall (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ACCUMULO-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Wall resolved ACCUMULO-4713.
------------------------------------
    Resolution: Fixed

> IteratorUtil.minimizeEndKeyTimestamp() and IteratorUtil.maximizeStartKeyTimestamp() may not set correct ranges
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: ACCUMULO-4713
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4713
>             Project: Accumulo
>          Issue Type: Bug
>            Reporter: Charles Williams
>            Assignee: Charles Williams
>            Priority: Minor
>              Labels: pull-request-available
>             Fix For: 1.7.4, 1.8.2, 2.0.0
>
>          Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> If a Key with a Long.MAX_VALUE timestamp is the startKey of the Range passed to maximizeStartKeyTimestamp() or a Long.MIN_VALUE timestamp is the endKey of the range passed to minimizeEndKeyTimestamp() the returned Range will not have inclusive set to true for the start/end Key. 
> This was observed while using the VersioningIterator and table.scan.max.memory setting. When the scan range includes matching Keys of which one has the timestamp of Long.MAX_VALUE the table.scan.max.memory can be set such that a reseek will be performed starting with the Key that has a Long.MAX_VALUE timestamp. The result is that the Key with Long.MAX_VALUE will be returned from the first batch, and the value will not be considered when evaluating the second batch, since the Range will not be modified to be inclusive when calling IteratorUtil.maximizeStartKeyTimestamp(), leading to the next (matching) Key also being returned. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)