accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-4713) IteratorUtil.minimizeEndKeyTimestamp() and IteratorUtil.maximizeStartKeyTimestamp() may not set correct ranges
Date Thu, 05 Oct 2017 21:51:00 GMT

    [ 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)

Mime
View raw message