accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David O'Gwynn" <>
Subject Re: Thrift proxy: Python WholeRowIterator behavior
Date Mon, 14 Apr 2014 03:17:49 GMT
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 from the old and new and got this:

<     (5, TType.I64, 'timestamp', None, None, ), # 5
>     (5, TType.I64, 'timestamp', None, 9223372036854775807, ), # 5
<   def __init__(self, row=None, colFamily=None, colQualifier=None,
colVisibility=None, timestamp=None,):
>   def __init__(self, row=None, colFamily=None, colQualifier=None, colVisibility=None,

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

View raw message