accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Newton (JIRA)" <>
Subject [jira] [Resolved] (ACCUMULO-1994) proxy does not handle Key timestamps correctly
Date Thu, 02 Jan 2014 17:44:02 GMT


Eric Newton resolved ACCUMULO-1994.

    Resolution: Fixed

> proxy does not handle Key timestamps correctly
> ----------------------------------------------
>                 Key: ACCUMULO-1994
>                 URL:
>             Project: Accumulo
>          Issue Type: Bug
>          Components: proxy
>    Affects Versions: 1.4.4, 1.5.0
>            Reporter: Brian Loss
>            Assignee: Eric Newton
>             Fix For: 1.4.5, 1.5.1, 1.6.0
> The proxy thrift IDL does not declare any default values for the Key struct.  This means
that timestamp will default to 0.  However, in Java it defaults to Long.MAX_VALUE.  This means
that ranges created through the proxy may behave differently than ranges created in Java.
 For example, say in Ruby I create a range as follows
> {code}
> range = => => "row1"), :startInclusive => true,
:stop => => "row2"), :stopInclusive => true)
> {code}
> This range will not include any keys in row1 that don't have a column family, qualifier,
or visibility since timestamp of 0 sorts last.  If I created the same range in Java, those
keys would be included.
> Change the thrift IDL to declare 0x7FFFFFFFFFFFFFFF (Long.MAX_VALUE) as the default value
for timstamp so that the thrift-generated Key class behaves the same way as the Java version.
> [~kturner] pointed me to the getRowRange helper method on the AccumuloProxy service.
 This method helps in some cases, but not the case I mentioned above since I have two arbitrary
rows.  Also, in looking through the code in ProxyServer, Keith noticed that the code does
not seem to handle timestamps correctly.  For example, the getRowRange method does not pass
a timestamp at all (not even the EMPTY value).  Also, the internal helper method getProxyKey
ignores the timestamp on the incoming key.

This message was sent by Atlassian JIRA

View raw message