accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David O'Gwynn" <dogw...@acm.org>
Subject Re: Thrift proxy: Python WholeRowIterator behavior
Date Mon, 14 Apr 2014 03:37:46 GMT
Lol. Search JIRA before banging head against wall. Noted. :-D

On Sun, Apr 13, 2014 at 11:32 PM, Sean Busbey <busbey@cloudera.com> wrote:
> 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