@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 <[email protected]> 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 >> >
