accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: Thrift proxy: Python WholeRowIterator behavior
Date Mon, 14 Apr 2014 03:32:25 GMT
Oh! that's ACCUMULO-1994. The ticket explains the root problem. In the
1.5.0 Proxy, the timestamp defaults to 0. Since columns sort on timestamp
in reverse order, that means nothing in the start row gets included (unless
the rest of the key components are 0).

[1]: https://issues.apache.org/jira/browse/ACCUMULO-1994


On Sun, Apr 13, 2014 at 8:17 PM, David O'Gwynn <dogwynn@acm.org> wrote:

> Urgh. If I run your code with the 1.5.1 Thrift interface, behavior's
> not there. If I run it with the one I downloaded, I get the behavior.
> I diff'ed the ttypes.py from the old and new and got this:
>
> <     (5, TType.I64, 'timestamp', None, None, ), # 5
> ---
> >     (5, TType.I64, 'timestamp', None, 9223372036854775807, ), # 5
> 228c228
> <   def __init__(self, row=None, colFamily=None, colQualifier=None,
> colVisibility=None, timestamp=None,):
> ---
> >   def __init__(self, row=None, colFamily=None, colQualifier=None,
> colVisibility=None, timestamp=thrift_spec[5][4],):
>
> I hand-jammed that timestamp default (sys.maxint) into my codebase and
> presto: fixed. So, I was obviously working off of an old Thrift
> interface version. Fail.
>
> Still not sure why that would fix it. The skip condition in WRI's seek
> method requires both that the timestamp be Long.MAX_VALUE and
> Range.isStartKeyInclusive() be false. The only thing that I can think
> is that the versioning iterator somehow resets the Range to the
> correct defaults. [/shrug]
>
> Regardless, I think the issue is actually settled. Again, thanks,
> Josh, for the patience.
>
> On Sun, Apr 13, 2014 at 10:00 PM, Josh Elser <josh.elser@gmail.com> wrote:
> > On 4/13/14, 9:13 PM, David O'Gwynn wrote:
> >>
> >> If the versioning iterator is attached, and the WRI's priority is <=
> >> the versioning iterator's priority, then you see this behavior (the
> >> first row of a WRI scan gets dropped). If you change the priority for
> >> the WRI in your code to <=20, then you'll see it, Josh.
> >>
> >> Still not sure why this would be the case; seems an odd behavior.
> >> Anyway, thanks for taking the time to help me suss this out.:-)
> >
> >
> > Hrm, interesting.
> >
> > What you described with the versioning iterator doesn't make much sense,
> but
> > I tried it out anyways. Setting WRI below versioning didn't change the
> > results. Also, completely removing the versioning iterator didn't change
> > anything.
> >
> > For fun, I inserted some new values for the same key and ensured that I
> got
> > both values when versioning was configured below.
> >
> > I'm still not sure what exactly the root of your problem.
>



-- 
Sean

Mime
View raw message