Sans the CountingIterator in o.a.a.t.Compactor incrementing an
AtomicLong every 1k, they are exactly the same class.
On 11/23/13, 7:55 PM, David Medinets wrote:
CountingIterator is declared in both of these places:
org.apache.accumulo.core.iterators.system.CountingIterator
The one in tserver also counts across all deep copies of the iterator. It
looks like the tserver one is used for providing compaction stats, and the
one in core is used only for testing iterators (mainly to verify that seek
optimizations are being performed correctly by checking the number of
In an effort to learn the Accumulo code, I've been working through it and
writing Javadoc along the way. I'd like to start contributing it to the
project. Is the best way to do that simply to create new JIRA tickets
covering the contributions? I have a lot so far, but I would only submit
I'd say... it depends on what you're documenting and how you're
documenting it. Tests for correct behavior, with comments about the
expectations, are often better than javadocs for internal,
implementing, code and a single ticket for a single set of related
tests/documented expectations seems
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15846/
---
(Updated Nov. 25, 2013, 9:37 p.m.)
Review request for accumulo, Adam Fuchs,
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15846/#review29396
---
core/src/main/java/org/apache/accumulo/core/conf/Property.java
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15846/#review29395
---
core/src/main/java/org/apache/accumulo/core/conf/Property.java
Thanks Christopher, for your well-thought-out advice.
I have been generating javadoc for anything with visibility public or
protected, and so I think that extends beyond the public API (I forget
its definition). I believe documentation of even internal methods is useful
for someone like me who is
