accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Charles Williams (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ACCUMULO-4713) IteratorUtil.minimizeEndKeyTimestamp() and IteratorUtil.maximizeStartKeyTimestamp() may not set correct ranges
Date Mon, 02 Oct 2017 18:12:02 GMT

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

Charles Williams updated ACCUMULO-4713:
---------------------------------------
    Description: 
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. 

  was: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. 


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