You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "Christopher Tubbs (JIRA)" <ji...@apache.org> on 2017/10/05 21:51:00 UTC

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

    [ https://issues.apache.org/jira/browse/ACCUMULO-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193790#comment-16193790 ] 

Christopher Tubbs commented on ACCUMULO-4713:
---------------------------------------------

Is this issue done? The PR is closed. If it's done, it needs a fixVersion and to be marked "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
>          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)