accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dylan Hutchison <dhutc...@mit.edu>
Subject Re: Unexpected aliasing from RFile getTopValue()
Date Wed, 15 Apr 2015 01:51:44 GMT
@Josh, the specific location is core/file/rfile/RFile.java, line 577 on
branch 1.6
<https://github.com/apache/accumulo/blob/1.6/core/src/main/java/org/apache/accumulo/core/file/rfile/RFile.java#L577>.


@Christopher, good point. I've avoided rethinking the entire SKVI interface
because it would be a gargantuan change, but it's worth doing.  And it may
lead to a better outcome than pointing out a bunch of local thoughts on the
iterator design.  Let's see if I can collect some thoughts before the
Accumulo summit.

~Dylan

On Tue, Apr 14, 2015 at 9:42 PM, Josh Elser <josh.elser@gmail.com> wrote:

> Do you mean to say you see this from the RFile Reader?
>
>
> Dylan Hutchison wrote:
>
>> While debugging a custom iterator today to find the source of a logical
>> error, I discovered something an iterator developer may not expect.  The
>> getTopValue() of RFile returns a reference to the RFile's internal Value
>> private variable.  The private variable is modified inside RFile via
>>
>>
>>     val.readFields(currBlock);
>>
>>
>> which means that if an iterator stores the reference from getTopValue(),
>> that is, without copying the Value to a new Object, then the value will
>> be updated in the iterator when the RFile's next() method is called.
>>
>> Here is an example snippet to demonstrate:
>>
>>     Value v1 = source.getTopValue();
>>
>>     source.next();                                   // v1 is modified!
>>
>>
>> The following code would not have a problem:
>>
>>     Value v1 = new Value(source.getTopValue());
>>
>>     source.next();
>>
>>
>> I bet this is done for performance reasons.  Is this expected?
>>
>> Regards, Dylan
>>
>

Mime
View raw message